HCL Workload Automation: How to drive your workload by business logic https://blog.hcltechsw.com/workload-automation/hcl-workload-automation-how-to-drive-your-workload-by-business-logic/
HCL Workload Automation: ビジネス ロジックによってワークロードを駆動する方法
2023年8月2日
著者: RICCARDO PIZZUTILO / Technical Sales Specialist, HCL Workload Automation
HCL ワークロード オートメーション ソリューションを使用してワークフローをジョブ ストリームに設計する場合、プロセス全体が単純なパイプラインとしてモデル化されておらず、予測されたフローチャートの実装に分岐と決定ロジック (IF… THEN.. ELSE…) が必要になる場合があります。 。
HCL Workload Automation の条件付き依存関係機能を使用すると、この設計上の問題を非常に簡単に解決できます。 多くのユースケースで条件付き依存関係を作成して使用する方法を見てみましょう。
まず最初に、条件付き依存関係とは何ですか?
これは、特定のステータスに達した場合、または親ジョブで特定の出力条件が検証された場合に解放されるジョブの依存関係です。 条件が満たされない場合、依存ジョブは抑止されます。
ジョブ ステータスに対する条件付き依存関係について考えると、これは親ジョブが成功で終了するかキャンセルされた場合に解放される標準的な依存関係を一般化したものであると断言できますが、条件付き依存関係では、ABEND または RUNNING 状態であっても、あらゆるステータスを要件としてマップできます。 。
親ジョブの完了時に満足できない場合、子ジョブは標準の依存関係のように HOLD ステータスのままではなく、SUPPRESS 状態になります。
最初のユースケースのシナリオは次のとおりです。
使用例 1: エラー管理
この使用例では、スケジューラは、PRINT_ANSWER ジョブがエラーで終了した場合に備えて、ジョブ ストリームの処理を区別したいと考えています。
この目標を達成するには、PRINT_ANSWER からジョブ PROCESS_DATA の依存関係を作成し、それに条件付き依存関係としてフラグを付け、ステータスを SUCC として選択するだけで十分です。一方、MANAGE_ERROR ジョブの条件付き依存関係は ABEND ステータスに関連付けられます。
この図からわかるように、PRINT_ANSWER ジョブが成功すると、MANAGE_ERROR ジョブは抑制され、通常の PROCESS_DATA ジョブが実行されます。
場合によっては、ジョブのステータスではなく戻りコードに応じて、ジョブ ストリーム フローを異なる方法で管理する必要があります。
別の例を見てみましょう。
ユースケース 2: 戻りコードによる分岐
上の図に示すように、ジョブ ストリームは、ジョブ START の 2 つの異なる成功リターン コードを管理するために分岐しています。
ジョブ START には、「ゼロ」と「4」というラベルが付けられた 2 つの異なる成功出力条件があり、ジョブ CHILD_0 と CHILD_4 は、それぞれの出力条件に基づく条件付き依存関係でジョブ START に依存しています。
この例では、START の終了コードは 4 で、条件「4」が true ですが、条件「zero」が false であるため、ジョブ CHILD_0 が抑制され、ジョブ CHILD_4 が実行されます。
処理要件をより複雑にしてみましょう。ジョブ ログの内容、データベース クエリの結果、または RESTful ジョブの応答として受信した JSON の特定の値 (ジョブにマップされたステータスではなく) に基づいてワークフローを分岐するなどです。 ジョブ) は別のシナリオで説明します。
使用例 3: 変数の内容による分岐
この例では、ジョブ ステータスに影響を与えない条件 (「その他の出力条件」フィールド) がジョブ MESSAGE に対して作成され、変数 ${this. を使用してジョブ ログ内の文字列「KO」または「OK」の存在を評価します。 stdlist}で処理を分岐します。 後続ジョブには「実行時の変数解決」フラグが設定されている必要があることに注意してください。
ジョブ ログ変数の使用に代わる可能な方法としては、サービスによって応答として受信された JSON ファイル、または、 RESTful ジョブ定義の詳細セクション。 別の例として、データベース ジョブ タイプの SQL クエリ内の列ラベルにちなんで名付けられた変数を使用できます。
ここで、2 つの異なるブランチでは要件を満たさないが、次の使用例のように複数のブランチを実装する必要があると想像してください。
使用例 4: 複数の分岐
親ジョブのジョブ ステータスに影響を与えない 7 つの異なる出力条件を作成し、複数の分岐フローを実装するために、出力条件ごとに 1 つずつ、7 つの異なる条件依存関係を設定しました。
次に、ジョブ ストリーム内でフローを分岐する方法を学びました。 よくある質問: 支店に参加することは可能ですか? はい、次の使用例で説明するとおりです。
使用例 5: ブランチの結合
この図の下部にあるジョブは、特別な依存関係の種類である結合依存関係に依存しています。 結合依存関係に 1 つ以上のジョブを追加し、解決基準を「すべて正常に完了」または「1 つが正常に完了」、または一般的には希望する数のジョブの一部に設定できます。
ブランチが相互に排他的である場合、または図のように 7 つのうち 1 つを指定した場合、1 つのブランチのみが正常に完了して最後のジョブを解放するだけで十分です (他のブランチは抑制されます)。
ジョブ ストリームの論理分岐への取り組みは終わりに近づいていますが、終了する前に次のことを覚えておいてください。各ブランチに複数のジョブのシーケンスを追加する必要がある場合は、条件付き依存関係を有効にして親子ジョブを連結する必要があります。 親ジョブの SUCC 状態によって異なります。
このトリックが本当に必要なのは、追跡されていないブランチ内のチェーンの最初のジョブが抑制され、従来の依存関係定義のデフォルトの動作が子ジョブを実行のために解放することであるためです。 次に、チェーンの 2 番目のステップが実行を開始しますが、望ましい結果はブランチ パイプライン全体が抑制されることです。
親ジョブが SUCC 状態にある場合にのみ依存関係を強制的に解放すると、必要に応じてブランチ内のジョブがカスケード抑制されます。
条件付きロジックの設計を楽しんでください。
HCL Workload Automation の詳細については、こちらをご覧ください。
Workload Automation: More than 100 Plugins Lets You Automate More (and Better) の翻訳版です。
HCL Workload Automation: 100 を超えるプラグインにより、より多くの (そしてより優れた) 自動化が可能です
2023年7月24日
著者: Ernesto Carrabba / Product Manager, HCL Clara, HCL HERO and HCL Workload Automation
Automation Hub は、IT ワークロードとビジネス ワークロードを調整する HCL Workload Automation の機能を紹介しています。
DevOps ニーズ、デジタル エンタープライズ、ハイブリッド クラウド オートメーション、アーキテクチャの自動化とオーケストレーションは、思いつくものであれば何でも、IT タスクの自動化からロボットによるプロセスの自動化まで、幅広いニーズをカバーします。
Automation Hub は革新的な進行中の作業であり、定期的にさらに多くの項目が追加されています。 中身を見てみましょう。
これは、プラグインの使用を増やすさまざまなタイプのオブジェクトとテンプレートのライブラリであり、すぐに使用できる統合、レポート テンプレート、プレイブック、イベント アクション、さらには顧客のさまざまなニーズに応じて実際にはさまざまなタイプのアイテムが含まれます。 さらに良いことに、その統合を作成してリリースすることもできます。 また、ビジネス パートナーは Automation Hub 上にプラグインを作成しました。最も良い点は、顧客も自動化を試したい場合にプラグインを作成できることです。
ここでは、Workload Automation プラグインのカタログ全体に接続できます。 さらに、各プラグインのビジネス シナリオを読んで、プラグインがなぜ重要なのか、グローバル ワークロード シナリオにどのように適合するのかをより深く理解できます。
すぐに使えるプラグインに焦点を当てると、現在までに 100 を超えるプラグインがあります。
もちろん、すべて追加料金はなく、数回クリックするだけでダウンロードして使用できます。
これらのプラグインは次のシナリオをカバーします。
いくつかのドメインのサンプルをいくつか紹介します。
Automation Hub では、30 を超えるケース スタディ (ビジネス シナリオ)、50 を超えるブログ投稿、各プラグインの膨大な数の製品スクリーンショット (使用方法を段階的に説明できます) など、さらに多くのコンテンツを提供しています。
HCL T-VREX: Being “Inside” of Troubleshooting の翻訳版です。
HCL T-VREX: トラブルシューティングの「内部」について
2023年7月26日
著者: Udo Blank / Technical Advisor, HCLSoftw
ペースの速いビジネスの世界では、問題を迅速かつ効率的に解決することが、ビジネスに不可欠なプロセスを成功させるために非常に重要です。 このようなシナリオでは、協力と効果的な問題解決が不可欠です。
HWA は、さまざまな業界のバックエンド プロセスを自動化する強力なツールです。 特に、銀行、保険、製造、自動車など、複雑で高度に規制されたプロセスを扱う業界で優れています。
HWA を使用すると、幅広いビジネス シナリオを効果的に処理できます。 これはオーケストレーション ソリューションとして機能し、個々のジョブのセットアップと、対応するジョブ チェーンまたは「ジョブ ストリーム」への統合を可能にします。 これらのジョブとジョブ ストリームは特定のスケジュールで実行でき、自動化されているため、効率と精度が保証されます。
今日の世界では、Workload Automation がなければ、組織は生き残ることが困難になるでしょう。 HWA は、デジタル + 経済、つまりハイパーコネクテッド デジタル化を特徴とする時代に向けて企業を準備する上で極めて重要です。 HWA を活用することで、組織はこの新しいデジタル環境で常に先を行き、成長できます。
しかし、問題が発生したり、ジョブ ストリームに時間がかかりすぎたり、中断されたり、キャンセルされたりした場合はどうなるでしょうか? HWA がどのように役立つかを見てみましょう。
HWA は、この目的のために、カスタマイズ可能で明確な広範なダッシュボードを提供します。 適切なドリルダウン オプションを使用して原因を迅速に特定し、是正措置を開始できます。 しかし、私たちがここに移動しているのは二次元の世界です。 オペレーターは通常一人で作業しており、画面共有を介して同僚と共同作業することも困難です。
HWA は、この問題に対して追加のコンポーネントである HCL T-VREX (“Troubleshooting Virtual Room Experience”) を提供しています。
VR メガネを使用し、ジョイスティックで制御することで、オペレーターは文字通り「3D WAR Room」に没入できます。 この仮想空間には、2 次元の世界の 1 つまたは複数のモニターで表示できるよりもはるかに多くのグラフィックスと KPI が表示されます。 ジョブとジョブ ストリームのステータスがより鮮明になります。 元の問題の原因は、複数のレベルにわたって迅速に発見、分析、除去できます (「ドリルダウン」)。
HCL T-VREX は、個々のオペレーターに利点を提供します。 同僚を連れてくる可能性があるため、複数のオペレーターが同じ仮想空間内を移動し、互いにコミュニケーションできます (オペレーターは他のオペレーターには「アバター」として表示されます)。 これにより、特に異なる場所にいる場合に、真のチームワークが可能になります。
これにより、ソリューションを見つける際のさまざまなオペレーターの経験が最適に組み合わされます。 原因を見つけるためには、さまざまな方法を同時に実行できます。 問題はより迅速に発見され、適切な解決策が調整されます。
その結果、ビジネスクリティカルなプロセスと手順が再び「稼働」します。 その結果、ダウンタイムが減少し、自動化されたビジネス プロセスが引き続きビジネス目標の最適化に役立ちます。
コンポーネントとしての HCL T-VREX は、「HCL Automation Power Suite」の一部です このスイートには、ビジネス プロセスのオーケストレーションのためのコア ソリューション HWA が含まれているだけではありません。 また、「オートメーション ハブ」(さまざまなサードパーティ ソリューションを自動化するための多数の統合)へのアクセスも含まれます。 HCL T-VREX に加えて、インテリジェントな操作のための他のコンポーネントも提供されています。
HWA の主な利点:
HWA は、分散システム、メインフレーム、クラウド、ハイブリッド、コンテナなどのさまざまなシステムにわたる一元的なエンドツーエンド制御を介して、どこにいてもワークロードを自動化および調整します。 同時に、オンプレミス、Kubernetes、クラウドのどのシステムでも運用できます。
HCL T-VREX、HWA、その他のコンポーネントについてご質問がございましたら、お気軽にお問い合わせください。
Unlock the power of automation with HCL Workload Automation の翻訳版です。
HCL Workload Automation で自動化の力を解き放つ
2023年7月13日
Ernesto Carrabba / roduct Manager for HCL Clara, HCL HERO and HCL Workload Automation
Automation Hub では、新しい機能が継続的に導入され、常にイノベーションが進行中です。 さらに深く掘り下げて、それが提供するものを探ってみましょう。
Automation Hub は、HCL Workload Automation の機能を強化するさまざまなオブジェクト、テンプレート、プラグインを収容する包括的なライブラリとして機能します。 すぐに使える統合、レポート テンプレート、プレイブック、イベント アクション、その他のさまざまなアイテムを提供して、顧客の多様なニーズに対応します。 さらに、当社のビジネス パートナーが行っているのと同じように、統合を作成して共有することもでき、顧客が自動化に積極的に参加できる共同作業環境を促進できます。
Workload Automation プラグインの広範なカタログを探索するには、Your Automation Hub にアクセスしてください。 各プラグインには詳細なビジネス シナリオが付属しており、その重要性と、より広範なワークロード シナリオにどのように適合するかを理解するのに役立ちます。
現在、Automation Hub には 100 を超えるプラグインがあり、すべて追加料金なしで利用できます。 お客様は、数回クリックするだけでこれらのプラグインを簡単にダウンロードして実装できます。
これらのプラグインは、金融サービス、ヘルスケア、保険、小売、エネルギー、自動車、製造、通信などの業界に対応する幅広いシナリオをカバーしています。
いくつかのドメインを詳しく見てみましょう。
Automation Hub は、広範なプラグイン コレクションに加えて、30 を超えるケース スタディ (ビジネス シナリオ)、50 を超えるプラグイン関連のブログ投稿、および大量の製品スクリーンショットを提供します。 これらのリソースは、特定のニーズに合わせて自動化の力を活用する方法を段階的にガイドします。
結論として、Automation Hub は、組織が HCL Workload Automation とその一連のプラグインを使用してより効果的に自動化できるようにします。 継続的な更新と豊富なサポート コンテンツを備えた、イノベーションと知識のハブです。 今すぐ Automation Hub にアクセスして、自動化への取り組みに革命を起こしましょう。
HCL DevOps and HCL Workload Automation Join Forces at SAP ALM Summit の翻訳版です。
HCL DevOps と HCL Workload Automation が SAP ALM Summit で協力
2023年7月10日
著者: Cristina Suchland / HCLSoftware
HCLSoftwareは、7月25日から27日までインドのベンガルールにあるSAP Labsで開催されるSAP ALM Summit APJでシルバースポンサーを務めることになりました。私たちのスポンサーシップにより、参加者はSAPの展望を後押しするHCL DevOpsとHCL Workload Automation製品について詳しく知ることができます。
貴社のGo-to-Marketの機会をサポートする HCLSoftware の製品をご存知ですか?
簡単に見てみましょう。
HCL Workload Automation + SAP = より良い連携
SAP向けのHCL Workload Automation統合により、SAPユーザーは使い慣れたソフトウェア環境を活用してサービスデリバリーを改善し、企業間のジョブの監視と管理を簡素化できます。HCLSoftwareのプラットフォームは、継続的な自動化のためのメタオーケストレーターとして機能し、コンテナ化と直感的なユーザーインターフェイスを活用しながら、市場で最も低い総所有コスト(TCO)を提供します。HCLのSAP統合とプラグインにより、ERPプロセスを最大限に活用できます!
HCL DevOps + SAP = チームワーク
HCLSoftware DevOpsへの投資は、あなたのチームが知っていて愛しているツールやプラットフォームを置き換えることを意味しません。その代わりに、SAP、Jira、Jenkins、Git、Kubernetesなど、すでに持っているツールを最大限に活用するお手伝いをします。Accelerate、OneTest、Launch などの当社製品を使用することで、マルチクラウドベースのアプリケーションデプロイメントとリリースオーケストレーション、あらゆる CI/CD ツールとの統合、バリューストリーム管理、エンタープライズ DevOps プラクティスと NZDT (Near Zero Down Time) によるブルーグリーンなデプロイメント戦略に関する洞察を得られます。
HCLSoftware のソフトウェアに興味をお持ちですか?イベントでお話しましょう!
Case Study: Insurance Claim Registration & Validation through HWA の翻訳版です。
ケーススタディ: HCL Workload Automation による保険請求登録と検証
2023年7月3日
著者: Sriram V / Technical Advisor-Workload Automation
今回は、HCL Workload Automationがどのように保険ビジネス側のエンド・ツー・エンド・プロセスを模倣できるかについての4回にわたるブログ・シリーズの第1回目です。
この最初のブログでは、以下のプロセスを見て、HCL Workload Automationを介してエンドツーエンドでそれを模倣してみます。
保険金請求は、手動フォームまたはオンラインで、同封されたすべての書類とともに提出された場合、請求フォームの詳細と、添付されたすべての書類の両方について、完全性を検証する必要があります。
この完全性チェックには、手書きの場合は申請書をスキャンし、提出された添付書類一式をスキャンする必要があります。
このブログでは、スキャンプロセスにDocusumo APIを使用していますが、IBM Discovery APIやGoogle Cloud Vision APIなどの同等製品で代用することもできます。
スキャンされたデータはドキュメントと一緒にMongo DBにドキュメントとしてアップロードされます。
この場合、保険会社はMongo DBにアップロードするためのAPIをPythonで開発しています。
ビジネスプロセスを実行するためのすべてのデータ検証と条件分岐ロジックはHWAによって処理されます。
この精巧なプロセスの最初のステップでは、顧客側からフォームで送信された保険データをスキャンします。これはHWAジョブで実行され、Docusumo Extract Data APIを呼び出してドキュメントを直接スキャンするRESTFUL Getジョブを採用します:
HWA 側で RESTFUL Get Job を呼び出します:
HWA 側で返されるレスポンスは以下のようになります:
フォームから気づいたように、保険金請求者の住所、日付、入院請求、保険金請求番号、医療費請求額、OPD請求額、SSN番号、納税者番号、請求総額、タイプ、IDなど、スキャンされたすべての詳細が正常に抽出されます。
保険データをアップロードするために、同社はRESTFULジョブを介して顧客データを格納する内部Mongo DBにこのデータをアップロードするフローのジョブを採用しています。
Mongo DBへのアップロードには、同社が開発したCRUD操作用のAPIが利用されます。
HWA からのRESTFULコール
HWAジョブでMongo DBにアップロード:
ドキュメンテーションの画像は同じDocusumoの "Extract Data API "を介してスキャンされ、ドキュメンテーションセットからJSON形式でドキュメンテーション証明書のすべてのデータをキャプチャしてデータが抽出されます。
APIを呼び出すRESTFULポストジョブはドキュメントセットから取り込んだすべてのデータを希望通りにMongo DBにアップロードします:
フォームデータの完全性チェックは、HWAジョブを経由して、バックグラウンドで実行されている内部APIを経由して、同じMongoDBにRESTFUL GETコールを行うことで行うことができます。
お気づきのとおり、住所、病院請求書番号、入院費、医療費請求書、医療費請求書番号、名前、OPD 請求書番号、OPD 料金、電話番号、SSN 番号、タイプ、ID などの詳細がキャプチャされます。キャプチャされたフィールドの一部は次のとおりです。 医療費請求フィールドや医療費請求書番号などの空白は、完全性の問題を示す N/A としてキャプチャされます。
この特定のジョブには、"NOT COMPLETE "と呼ばれる条件として変換するために、フィールドに返されたN/Aの文字に対する条件依存チェックがあります。
これにより、別のメール ジョブが呼び出され、ドキュメントが完了していないことを通知する電子メールが送信され、顧客は請求が現在保留中であることが通知されます。
保険データの完全性チェックもRESTFUL GETジョブによって行われ、フォームの完全性にミスがあった場合、すぐに把握することができ、同じことがEメールでリアルタイムに通知されます。
ジョブの類似条件依存性により、データが「該当なし」を返した場合、同じデータがキャプチャされ、条件が満たされると、「保険金請求者の住所」、「日付」、「入院請求」、「保険金請求番号」、「医療費請求」、「OPD」、「SSN番号」、「タックスID番号」、「請求総額」、「タイプ」などのすべての詳細がキャプチャされます。
キャプチャが完了すると、このケースではメール通知ジョブは抑制されます。
さらに、これらのメール通知ジョブからの条件付き依存関係もあり、両方のメール通知ジョブが "SUPRESS "状態になったときにのみ、クレームが "COMPLETE "状態で登録されたとマークされます。
mail-intimation-jobs.png
HWA側で見た全体の流れは以下のとおりです。
HCL Workload Automationの詳細については、こちらをご覧いただくか、HWAinfo@hcl.com までご連絡ください。
Case Study: Data Pipeline Orchestration ETL Use Case の翻訳版です。
ケーススタディ: データパイプラインオーケストレーションの ETL ユースケース
2023年6月12日
著者: Sriram V / Technical Advisor-Workload Automation
このブログでは、HCL Workload Automation のデータパイプラインオーケストレーションの完全なエンドツーエンドのユースケースを紹介します。
このシナリオでは、HCL Workload Automation を使用し、複数のソースシステムからデータが入力されるようにします。ファイルの検出やソースファイルの処理も、後処理を含めて異なるシステムで行われる可能性があります。
データ変換は、データステージング/変換プラットフォームを介して行われ、その後、変換されたデータをデータウェアハウスに取り込みます。データウェアハウスにデータが取り込まれると、一般的な分析プラットフォームを通じて、そのデータに対して分析を実行できます。
アナリティクスのステップでは、クエリーのステータスを確認できます。そのレスポンスを収集し、レポーティングツールからレポートを実行できます。
データパイプラインをエンドツーエンドでオーケストレーションする必要があり、異なるソースシステムからやってくる複数の受信インターフェースファイルがあるお客様は、このプロセスの恩恵を受けられるでしょう。インターフェイスファイルは到着時にリアルタイムで検出する必要があり、異なるシステムでリアルタイムに処理する必要があります。
顧客はメイン ERP として SAP を使用しており、SAP R/3 システムで、バリアントとステップユーザーを渡す ABAP プログラムで受信インターフェイスファイルを処理します。また、この顧客は、受信ファイルを処理するフローの一部として、SAPプロセスチェーンも実行させる必要があります。また、ソースファイルの1つをフェッチして別のターゲットにインポートするファイル転送ステップもある。
データ処理が完了したら、生成されたアウトプットを変換する必要があります。データ変換ツールとしては、Informaticaを使用できます。また、変換されたデータは、SAP Data Warehouse on the SAP HANA DBのようなデータウェアハウスに取り込む必要があります。
ここでは、インジェストされたデータの上でアナリティクスを実行するためにPowerBIをメイン製品として使用し、データソースをリフレッシュするためにPowerBIを使用されました。リフレッシュされたデータソースのステータスをフェッチし、そのステップを正常に終了させる必要があります。ステータスチェックの後、Workday Applicationを使用してレポートを実行し、それをユーザーに郵送することも必要です。
どのステップで失敗しても、MS Teamsにアラートが送信されます。また、ファイル転送のステップで処理中に3分以上かかると、MS Teamsにアラートが表示されます。
HCL Workload Automation は、このデータパイプラインをエンドツーエンドでオーケストレーションし、複数のアプリケーションを横断してフロー内の異なるジョブを実行します。
また、Workload Automationは、異なるソースシステムからのソースファイルを処理中にリアルタイムで検出し、ソリューション内で利用できるさまざまなプラグインを使用して各アプリケーションに容易に接続します。
個々のステップをリアルタイムで実行しながら、アラート、アベンド/フェイル、ロングランを追跡し、必要に応じて、自動化された条件分岐によってリカバリーが追跡されます。リカバリージョブやイベントルールは、自動リカバリープロセスで設定することも可能です。
ソースファイルは、イベントルールによって簡単に検出できます。ファイルは、リアルタイムまたはファイル依存のジョブストリームへのアクションで「作成」されます。
SAP R/3バッチジョブは、バリアントとステップユーザーでABAPプログラムを実行することで構成されています。
また、新しいスプール要求やプリンタフォーマット、スプール受信者の指定など、プリンタパラメータをここで実行することもできます。また、SM36内にあるようなパラメータをアーカイブすることも可能です。これらは、マルチステップのSAPジョブでも同様に使用できます。
HWAは、SAP内のSAPジョブログをリアルタイムでHWA内のローカルジョブログにフェッチします。
SAPプロセスチェーンジョブは、BWプロセスチェーンをトリガーするために、実行ユーザーを渡すオプション(これも内)を使ってBW SAPプロセスチェーンを実行することです。
ファイル転送ジョブは、外部のサードパーティとの間で、または内部で2つの異なるサーバー間でファイル転送をトリガーするために使用できます。
また、A2A(Agent to Agent)プロトコルを利用して、エージェント間でソースからデスティネーションへのhttps転送を行うオプションも用意されています。また、正規表現のマッピング、ソースでのアーカイブ、マッピング、ソースでのアーカイブ、日付とタイムスタンプ付きのデスティネーションでのアーカイブなどのオプションがあります。
この場合、ファイル転送のステップが長くなり、この特定のジョブで3分に設定された最大継続時間を超えてしまいます。
この結果、イベントルールを介してMS Teamsに通知アラートが送信されます。
データ変換は、InformaticaフォルダからInformatica PowerCenterワークフローを実行するInformaticaステップで行われ、サービスドメイン、リポジトリドメイン、リポジトリ名などにも言及されます。
Informatica 内での変換を示すジョブログは以下のようになります。
SAP HANA ジョブ
SAP HANA DBジョブは、SAP HANA DBに対してDBを照会したり、ストアドプロシージャを実行したりするために使用されます。これらは、ジョブ定義でSAP HANA NGDBCドライバについても言及しています。このジョブでは、以下のようにSAP HANA DBへのDBインポートを行うことになります。
注:データベースへのインポートをポストするために、データベースに取り込まれたデータの上でAnalyticsを実行することも可能です。
インポートをHANA DBにポストするための次のステップは、Power BIデータソースをリフレッシュすることです。これは、HWA内のRESTFULジョブで実現できます。
restfulジョブは、JSONボディを渡すことで、サービスURLを呼び出してhttpsポスト(この場合はpost)を行うために使用できます。ジョブのボディには、ファイルを経由するか、ボディフィールド内に直接投稿できます。
前のステップのステータスを別のRESTFULジョブで取得し、前のステップからDATASETIDとREFRESHIDを変数として渡して、前のステップのステータスでhttps GETを実行します。
JSONボディをジョブのbodyフィールドに直接渡すことで、再びRESTFULポストジョブを活用し、Workdayアプリケーションでレポートを実行します。
製品のグラフィカルなビューを使用することで、このプロセス全体をリアルタイムで追跡し、失敗や長いランナーをMS Team/チケットツール/メール/SMSで直接警告を受けることが簡単にできます。
HCL Workload Automationの詳細については、こちらをご覧ください。
AWS Actions and Events in HLC Workload Automation の翻訳版です。
HLC Workload Automation における AWS Actions と Events
2023年5月30日
著者: Shivansh Verma / Senior Software Engineer at HCLSoftware
AWS Actionsプラグインは、イベントを送信するための新しいEDWAアクションプラグインで、手作業をなくし、解決を大幅にスピードアップさせます。機能性を提供する作業管理ツールであり、ユーザーの作業を効率的に管理することができます。
このプラグインを使用して、定義されたポリシーに合致するジョブがエラー(Abend/Failed)で終了した場合に、AWS(SNS & SQS)においてイベントを送信します。これにより、単一のコントロールポイントからソリューションを監視することができます。
AWS Actions機能を使用すると、HCL Workload Automationが実行されるノードで発生したイベントに応答して、定義済みのアクションを起動することができます。このアクションは、AWS サーバー上でイベントを送信します。主な要素は、"イベント "と "アクション "のどちらかに分類されます。
イベントは、選択した条件に一致する一連の状況を表します。イベントは、以下の主要なカテゴリーに分類されます:
HCL Workload Automationオブジェクト関連イベント ジョブ、ジョブストリーム、ワークステーションなどのスケジューリングオブジェクトに関連するすべてのイベント。注:ルールで参照されるワークステーションで実行される変更は、ルールでは報告されません。例えば、ルールで参照されているワークステーションを変更、更新、または削除した場合、ルールはその変更を無視し、ルールに含まれていたときのワークステーションを引き続き考慮します。
ファイル監視イベント ファイルおよびログの変更に関連するイベント。ファイル監視イベントは、HCLシステムではサポートされていません。このタイプのイベントの詳細については、ファイルモニターで説明します。
一般的なイベント 外部アプリケーションから送信されるカスタムイベントを管理するために使用されるイベントです。カスタムイベントを定義するために、XMLファイルを記述することができます。XMLを検証するためのスキーマと、開始点として使用できる基本的なイベントテンプレートが提供されています。詳しくは、汎用イベントのスキーマを参照してください。このカテゴリのイベントは以下の通りです:
AWSサーバーの複数のサービス(SNS&SQS)に対してイベントを送信するアクションを複数作成することができます。
ここでは、AWS Actionsアクションプラグインの使用方法について説明します。 このプラグインは、ジョブ、ジョブストリーム、ワークステーションなどのHCL Workload Automationオブジェクト関連イベントに基づいてイベントを送信するのに役立ちます。
このプラグインを使用するには、Workload Automationで次のことを実行します:
このアクティビティは、新しく作成されたイベントルールをドメインマネージャーのマスターにデプロイするために短い間隔を要します。イベントルールのステータスは、「イベントルールの管理」ページで監視することができます。
Dynamic Workload Consoleにログインし、[デザイン]→[イベントルールの作成]ページを開き、イベントルールに関する必要な情報を入力して新しいイベントルールを作成します。
図1:イベントルールの作成ページ
すべてのイベントには、プランからあらかじめ定義された情報がセットで提供されます。イベントの追加ページでは、要件に応じて必要なジョブ関連情報をフィルタリングすることができます。
例えば、Job Status Changedイベントは、スケジューラープランのすべてのジョブ関連情報を取得します。FAIL/ABEND/ERRORのようなジョブステータスに基づいてイベントをフィルタリングすることができます。
図2:イベント追加ページ
図3:Add Event Page>Job Status(イベントの追加ページ)>Jobステータス
AWS Actionsアクションの追加
Add Action ページでは、以下のような AWS サーバーの必須接続関連情報を提供します: AWSアクセスキーID、シークレットアクセスキー、AWSリージョン、SNSサービスが選択されている場合はトピックARN、SQSサービスが選択されている場合はSQSキューURL。
Message Bodyテキストボックスに、各サービスに送信するメッセージを入力します。必須情報とは別に、メッセージ属性を使用して他の必須フィールドを提供することもできます。
注:メッセージ属性は、key=valueの形式である必要があります。
図4:アクションの追加ページ
グラフィカル・ユーザー・インターフェース、アプリケーション、電子メール 説明文は自動的に生成されます。
図5:Add Actionページ>Properties
グラフィカル・ユーザー・インターフェース、アプリケーション 自動的に生成される説明
図6: アクションの追加ページ > プロパティ
イベント固有の情報は、ここに示すように、変数の形で利用可能です。イベントに関する情報をさらに追加すると便利な場合があります。
アクションに必要な情報をすべて入力した後、イベントルールを保存します。
アクションの監視
このページでは、イベントルールのステータスが表示されます。
図7:モニターページ
変更がマスタードメインマネージャーに展開されると、ステータスは "active "に変更されます。
図8: モニターページ>ステータス
イベントルールの管理
トリガーされたアクションの監視」ページには、成功や失敗など、トリガーされたアクションに関する情報が表示されます。
図9:トリガーされたアクションの監視ページ
グラフィカル・ユーザー・インターフェース、表の説明の自動生成
図10: 課題の作成ページ > プロパティ