Interview: HCL Volt MX Hackathon winner, Vishal Vats (Part One) の翻訳版です。
インタビュー: HCL Volt MX ハッカソン優勝者、Vishal Vats (パート 1)
2023年8月4日
著者: Suhas Bhat / General Manager, HCL Volt MX
今年の初めに、HCL Volt MX が最初のハッカソンを主催しました。 8 週間で 4,300 人の登録者が集まり、数え切れないほどの素晴らしい応募があった後、最終的に勝者を発表しました。Vishal Vats です。
実際、Vishal は全体で 1 位になっただけでなく、最も革新的なアプリ賞も受賞しました。 ハッカソンの後、私たちは Vishal に会い、彼のアプリ Wishy と Volt MX の学習経験について聞く機会がありました。
以下のインタビューの最初の部分をご覧ください。
HCL Volt MX ハッカソンの優勝おめでとうございます! あなたが取り組んだプロジェクトと、そのプロジェクトが解決することを目的としたプロジェクトについて簡単に説明していただけますか?
Vishal: ありがとう、私が取り組んでイベントに提出したプロジェクトは Wishy です。 この忙しい時期に、私たちは愛する人たちの特別な日を祝うことを忘れがちです。 つまり、Wishy は、連絡先を追加して、誕生日、記念日、さらにはお祭りなどの特別な日の自動メール/SMS 通知をスケジュールできるアプリケーションです。これにより、愛する人を逃すことがなくなり、最初に願い事をする人になることもできます。 個人的な願いを通して彼らをサポートします。
ハッカソンに参加し、この特定のプロジェクトのアイデアを選択したきっかけは何ですか?
Vishal: 私はハッカソン/イベントに積極的に参加しており、終了の約 3 週間前に HackerEarth プラットフォームを通じて Volt MX ハッカソンのことを知りました。 Volt MX を使用することに私が興味をそそられたのは、このプラットフォームが、モバイル、Web、デスクトップ、さらにはタブレット向けの完全なスタンドアロン アプリケーションを作成できる単一のローコード プラットフォームを提供するという事実です。 それはすごいことではないでしょうか?
私はWebアプリの開発を長くやっているのでその辺は分かるのですが、JSの基礎を知っているだけでもAndroid/iOSアプリを作ることができて、とても参加する気になりました。 プロジェクトのアイデアについては、実はイベントの前から、自動化された願いの部分を本当に高度化できる Android (モバイル) アプリケーションを明確に作りたいと考えていました。 そのため、バックエンドがどのようなものになるかについての青写真が頭の中にあり、自分のアイデアを効果的に表現できる機会を待っていました。 それから、Volt Iris アプリケーションが提供するサービスを通じて、自分のアイデアを現実のものにし始めました。
「私は長い間 Web アプリケーションを開発してきたので、その部分は知っていますが、JS の基礎を知っているだけで Android/iOS アプリケーションを作成できるということで、イベントに参加する意欲が高まりました。」
Volt MX の機能をどのように活用してソリューションを作成しましたか? あなたのプロジェクトに特に役立つ特定の側面や機能はありましたか?
Vishal: 開始当初、このプラットフォームは、画面スペースのほぼすべてのピクセルにさまざまな機能とプロパティのパネルが多数ポップアップ表示されるため、少し気が遠くなるように思えました。 しかし、ソフトウェアを使い始めると、すべてのパネルがプロジェクトで何をどのように使用しなければならないかを徹底的に制御できるため、すべてが理にかなっていました。 プラットフォームが提供するほぼすべての機能を使用しました。
私のお気に入りの要素と言えば、セグメント (一般にそのページのバリアント) が私にとって非常に役に立ったと思います。なぜなら、まずセグメント テンプレートを定義し、Foundry から受け取ったデータをそこに設定できるからです。 セグメントのページ バリアントを使用すると、アプリケーションに多くの視覚的な魅力を追加するカルーセル形式でデータを表示できるため、プロジェクトで何度か使用しました。 リッチ テキスト部門も、通常のテキスト部門とは別の優れたバリエーションでした。なぜなら、リッチ テキスト部門では HTML コードを直接使用できるため、何も触れずに要素に対して特定のことを実現できるからです。 アクション フロー ダイアログは、要素のイベント リスナーを 1 か所に配置する際にも非常に役立ちました。
HCL Volt MX を、これまでに使用した他のローコード開発プラットフォームやフレームワークとどう比較しますか? その長所と短所は何だと思いますか?
Vishal: 私は Volt MX を使用するまでそのようなローコード プラットフォームを使用したことがありませんでした。なぜなら、私はコードを書くのが本当に好きで、フレームワークやテンプレートですべてをカスタマイズするのではなく、実際に自分で何かを書くことが常に好きだったからです。 しかし、Volt MX を使用した後はそうではないことを認めなければなりません。なぜなら、今ではアプリケーションの動作にとって実際に重要なものだけを書きたいと思っており、ソフトウェア上の他のものはすべて省略できるからです。
「プラットフォームが提供するほぼすべての機能を使用しました。」
振り返ってみて、Volt MX に関連してハッカソンに参加して得た最も貴重な教訓や洞察は何でしたか?
Vishal: 前述したように、最初の締め切り後にはランディング ページの UI がまったく異なっていましたが、ユーザーに提示される UI には本当に不満がありました。 時間の都合でリファインすることを諦めかけていたところ、突然延長が発表され、できるかもしれないという一縷の望みを抱きました。
HCLSoftware 製品サポートが TISAXR ラベルを取得: データのセキュリティと保護に対する当社の取り組みの証し
2023年8月7日
著者: Piet Gaarthuis / Director, Client Support 共著: Isha Gill / Senior Privacy & Security Specialist
私たちは、お客様のデータの最大限のセキュリティとプライバシーの確保に向けた取り組みにおける重要なマイルストーンを発表できることを嬉しく思います。 厳格な評価と厳格な評価を経て、TISAXR (Trusted Information Security Assessment Exchange) ラベルを取得することに成功しました。
TISAX は、自動車業界の情報セキュリティのために特別に設計された、堅牢で国際的に認められた評価および交換メカニズムです。 サプライチェーン内の情報セキュリティを評価および管理するための標準化されたアプローチを提供します。 ドイツ自動車産業協会 (VDA) によって開発された TISAX は、組織が機密情報を扱う際に厳しいセキュリティ要件を満たしていることを保証します。
独立監査法人であるビューロー ベリタスは、サポート サイトのオンサイトおよび仮想監査を通じて包括的な評価を実施し、TISAX フレームワークへの準拠を検証しました。 このプロセスには、ユーザー アクセス管理、セキュリティとプライバシーのトレーニング、運用セキュリティ、ネットワーク セキュリティ、暗号化標準、パスワード管理、事業継続性、リスク管理などを含む、サポートの手順と技術的保護手段の徹底的なレビューが含まれていました。
TISAXR ラベルの取得は、お客様のデータの保護に対する当社の揺るぎない取り組みを反映しており、当社を自動車業界内で信頼できるパートナーとしての地位を確立します。 この成果はサポート チームの総力の努力と献身的な成果であり、私たちはこの成果を非常に誇りに思っています。
結果は、ENX ポータル経由でのみ取得できます。 HCLSoftware Trust Center でラベルにアクセスする手順をご覧ください。
今後も当社は最先端のセキュリティ対策への投資を継続し、情報セキュリティ慣行を定期的に見直して更新し、データ保護の最前線であり続けます。
How HCL Workload Automation Revolutionizes the Insurance Claim Acceptance Process の翻訳版です。
HCL Workload Automation が保険金請求受付プロセスにどのような変革をもたらすか
2023年8月4日
著者: Sriram V / Technical Advisor-Workload Automation
これは、Workload Automation が保険ビジネス側のエンドツーエンドのプロセスをどのように模倣できるかを説明する 4 部構成シリーズの 2 番目の部分です。 (参考までに、シリーズの最初の部分へのリンクをここに示します。)
ここでは、以下のプロセスを調べ、HCL Workload Automation を使用してそれを模倣してみます。
保険請求は、受理プロセス中に完全性チェックを受け、すべての書類が保険請求の一部として提出されていることを確認します。 チェックの結果により、連絡先に電子メール通知が送信されるか、プロセスが次のステップに進むことが可能になります。
次のステップは、申し立てをエスカレーションする必要があるかどうかです。 エスカレーション要件により、さらなるレビューと承認のためにエスカレーションがポータルに送信される可能性があります。
請求ケースにエスカレーションが必要ない場合は、受入チェックが行われ、さらに明確な説明が必要な場合、または請求が受理されてシステムに登録される場合に備えて、請求は保留に設定されます。
請求フォームと文書に関するデータはすでに Mongo DB に保存されており、フォアグラウンドで公開されている Docusumo API を介して同じデータにアクセスできます。これを IBM Discovery API、Google Cloud Vision API などの同等の製品で置き換えることもできます。 。
保険フォーム データの完全性チェックは、Docusumo API を利用して RESTFUL GET 操作を実行し、Mongo DB (すべてのデータが存在する) からデータを取得する RESTFUL GET ジョブとして実現される HWA ジョブを介して実行されます。
このジョブのジョブログは次のようになります。
このジョブには、データが完全であるかどうかを判断するための条件付き依存関係もあります。
したがって、これはジョブログ内でキーワード「N/A」を検索し、データが完全であるかどうか、または以前に Docusumo から実行されたスキャンに欠落しているフィールドがあるかどうかを判断します。
保険添付データの完全性チェックは、バックグラウンドで実行されている内部 API を介してサービスされる同じ Mongo DB に対して、HWA ジョブを介して RESTFUL GET 呼び出しを行うことによって行われます。
ドキュメント データの完全性チェックは、ジョブ レベルで定義された条件付き依存関係を使用して再度検証されます。ジョブ ログ内の文字列「N/A」は、このデータがスキャンで利用できないか欠落していることを示し、その結果、条件「NOTCOMPLETE」が発生します。 満足する:
「NOTCOMPLETE」条件が満たされると、不足しているデータについて顧客に通知するために電子メールで顧客に通知を送信するメール ジョブが実行されます。
メール通知ジョブは、ドキュメントが完了していないことを示す通知を送信します。
CLAIM_ESCALATION ジョブ
これは、この場合にクレーム エスカレーションが必要かどうかをチェックする Unix ジョブとして実現されるため、呼び出されたスクリプトは、返された値が特定の値を超えているかどうかを評価します。
すべてのリターン コードが「REQ」、「NOT_REQ」にマップされる条件依存関係が定義されます。 したがって、戻りコード 5 または 0 に応じて、対応する条件 (必須または不要) が渡されます。
エスカレーションが必要な場合は、SEND_CLAIM_ESCALATION_PORTAL ジョブが呼び出され、ポータルに RESTFUL POST ジョブが実行されます。これにより、金額が特定の値を超えた場合に、より高い承認のためにクレームが上級管理者にエスカレーションされます。
MAKE_ACCEPTANCE_DECISION ジョブ
MAKE_ACCEPTANCE_DECISION ジョブは、AWS Lambda 関数または Google Cloud Functions を実行し、AWS または GCP 上でサーバーレス方式で実行されます。評価はバックグラウンドで Analytics を使用して実行されるか、Google Big Query ジョブまたは Azure Data Bricks ジョブの形式で実行されます。 以前の傾向から取得した履歴データや保険会社が作成したカスタム機能に基づいて請求が受け入れられるかどうか、または請求が「保留」になるか「受け入れられない」可能性があるかを確認します。
すべてのリターン コードが「ACCEPT」、「NOT_ACCEPTED」、「PENDING」のいずれかにマップされる条件依存関係が定義されます。 したがって、戻りコード 127、37、または 0 に応じて、対応する条件が渡されます。
要求保留設定のジョブ
このジョブは、Mongo DB で請求を保留に設定し、保険会社からのさらなるチェックのために請求を手動でさらに評価できるようにします。
「ACCEPT」条件を通過した場合、請求は「RESGITER CLAIM」ジョブによって受理され、請求の登録が正常に完了したことを通知するメール通知がメールジョブによって送信されます。
新しい試みのトライアルとして、1週間分のサポート技術情報更新のインデックスを作成してみました。しばらく継続してみます。新規追加と内容更新したものが含まれています。システム上、軽微な修正であってもリストに含まれてしまいます。予めご了解ください。
HCL AppScan DAST と脆弱なサードパーティコンポーネントの検出により、アプリケーションのセキュリティをより広範囲にカバー
2023年8月2日
著者: Kamal Kumar Chandrashekar / Senior Product Manager, HCL AppScan 共著: Ayan Som / Senior Product Manager, HCL AppScan
The Linux Foundation Research によると、現代のアプリケーションで使用されているアプリケーション コードの 70 ~ 90% はサードパーティ ライブラリに依存しています。 このソフトウェア サプライ チェーンの依存関係は、現代の開発の厳しいペースの直接の結果です。 特定のタイプの機能については、これらのコンポーネントを最初から作成するよりも、「既製」のコードを組み込む方がはるかに効率的です。
しかし、サードパーティのライブラリに依存することにはセキュリティ上の欠点があります。 チームがゼロから構築する独自コードには脆弱性がない可能性がありますが、サプライ チェーン内の外部アプリケーションやコンポーネントが脆弱であれば、アプリケーションが安全であるとは限りません。
依存する脆弱なコンポーネントは攻撃者に機会を与え、検出されないとアプリケーションやビジネスに重大な影響を与える可能性があります。
HCL AppScan DAST (動的アプリケーション セキュリティ テスト) は、潜在的な脆弱性に対してアプリケーションと API をスキャンする業界をリードするテクノロジーです。 HCL AppScan DAST は、自動スキャンを実行してリスクを評価し、展開前にリスクを軽減することで、高額な Web アプリケーションのセキュリティ侵害を防止します。
HCL AppScan DAST エンジンの主な強みの 1 つは、脆弱性の豊富なデータベースを活用できることです。 このデータベースは、世界中のクライアントにサービスを提供しながら 30 年以上にわたってトレーニングされ、アプリケーションの動作を分析し、アプリケーションのセキュリティ体制に関する貴重な洞察を提供します。
HCL AppScan では、脆弱なサードパーティ コンポーネントの検出が導入されました。 この新機能は、最もよく使用されているクライアントおよびサーバー側テクノロジーのフィンガープリントを取得し、それらの脆弱性を報告することにより、既存の DAST 機能を強化します。
コンプライアンスと監査 DAST および脆弱性サードパーティ コンポーネントの検出は、組織が非準拠コンポーネントを特定して対処し、必要な法規制遵守要件を確実に満たすのに役立ちます。
開発者の意識 サードパーティ コンポーネントに対するさらなる注意により、プロアクティブなセキュリティの文化が促進され、開発チームがソフトウェアの依存関係を定期的に監視して更新することが奨励されます。
リリース範囲 AppScan Standard 10.3.0 および AppScan Enterprise 10.3.0 リリース以降。
現在、非常に多くのサードパーティ コンポーネントがアプリケーションに組み込まれているため、それらのコンポーネントがコード ベースに脆弱性をもたらしたり、安全性を維持するためのすべての努力を台無しにしたりしていないかを知ることが重要です。
HCL AppScan DAST は、業界をリードするアプリケーションの機能テストを提供し続けます。 脆弱なサードパーティ コンポーネントのフィンガープリンティングが追加されたことで、開発チームはこれらの集約された結果をすべて集中ビューで確認できるようになり、トリアージと修復が容易になり、ソフトウェア サプライ チェーン全体のセキュリティが大幅に向上します。
脆弱なサードパーティ製コンポーネントの検出を備えた HCL AppScan DAST の詳細については、https://www.hcl-software.com/jp/products/appscan?referrer=blog.hcltechsw.com にアクセスしてください。
2023年8月3日、HCL Notes 9.0.1 FP10 IF12 と HCL Domino 9.0.1 FP10 IF11 をリリースしました。今回のリリースはセキュリティー修正です。詳細は以下の記事を参照してください。
リリースされたプログラム
The Zen of Cybersecurity: BigFix and the Path to Peace of Mind の翻訳版です。
サイバーセキュリティの禅 - HCL BigFix と安心への道
2023年8月2日
著者: Jérôme Boulon / Founder & CEO at NeoVAD
安心。誰もがそれを望んでいる。特に、データ漏洩、ランサムウェア、サイバー脆弱性や悪用が、痛みを伴い、避けられないように見える事実である常時接続の世界では。
私には提案がある。その前に、少し説明させてください。
ITソリューションのディストリビューターとして、私たちNeoVADは、リセラー・パートナーとその顧客に最も魅力的な製品を提供するための努力を惜しみません。ユーザー・エクスペリエンス、サイバーセキュリティ、クラウドおよびデータセンター・ソフトウェアに重点を置いた製品ポートフォリオで、私たちの目標はユーザーの生活を簡素化することです。その目的は、最適なエクスペリエンスを提供し、長期にわたってパフォーマンスを分析し、安全で弾力性があり信頼性の高い基盤の上で制約のない作業環境を実現することです。
"シンプルにする "という言葉を拡大解釈させてください。
安定性と自由を両立させるには、世界が提供する真の複雑性に対処しながら、生活をシンプルにするソリューションが必要です。データ・セキュリティの分野ほど重要なものはない。サイバーセキュリティの脅威は、あらゆるタイプの企業にとって絶え間ない懸念事項であり、現実の世界では、システムのスキャン、脆弱性の追跡、パッチの実装、さまざまな環境、ユーザー、チーム間での対応の調整など、複雑で終わりのないサイクルが企業に課せられている。内部要件や規制要件への準拠を文書化することで、すべてを公式にすることは言うまでもない。
実際には、それは混乱しかねない。また、多くのアドホックな活動を管理しなければならないため、IT運用を合理化し、パフォーマンスを最適化するというビジネス・レベルに存在する非常に現実的なニーズが、日々のデータ・セキュリティのゴチャゴチャした現実と痛いほど衝突する可能性があります。
私たちは、私たちを頼りにしてくれるパートナーやエンド・カスタマーのために、生活をシンプルにする努力をしていると申し上げました。混沌とした雑木林を切り開き、サイバー脅威の世界に秩序を与えるための最も重要なツールのひとつが、HCL BigFix と呼ばれるものです。
BigFixによって私たちがパートナーやその顧客のために何ができるのか、そしてなぜ私たちがBigFixに完全に依存しているのか、少しお話しさせてください。大きなトピックですが、私が考える最も重要な3つのことに焦点を当てます。
まず、BigFixは1つのエージェントでさまざまな種類のOSやアプリケーションをカバーします。この事実だけでも、私たちにとっては非常に大きなことです。パッチ・チューズデーが到来したとき、すべてのパッチを遅滞なく、しかも単一の場所から、世界中に散らばるオペレーティング・システム、環境、アプリケーション、ハードウェア、およびデバイスの正真正銘の大混乱にデプロイすることができるのです。たった1つのエージェントがあれば、仮想的にリスクをカバーすることができ、その上、運用を非常にうまく拡張することができます。
オンプレミスのハードウェアだけでなく、モバイルユーザーやクラウド環境も含め、数千台のサーバーやエンドユーザーに迅速に展開し、シームレスに拡張できるこのパワーは、BigFixの大きな差別化要因です。
次に、可視性の問題です。BigFixは、環境全体、チーム全体、そして組織全体にわたって、これら活動を可視化します。BigFixは、さまざまなオペレーティング・システム、アプリケーション、デバイスが混在する異種分散環境を一元的に把握することができます。さらに、このプラットフォームの監視機能により、システムの健全性とパフォーマンスをリアルタイムで可視化できるため、ビジネスへの影響が出る前に問題を特定し、プロアクティブに対処することができます。このアプローチにより、ダウンタイムを最小限に抑え、パフォーマンスを最適化し、エンドユーザー・エクスペリエンスを向上させることができます。
3つ目の質問である自動化について説明します。まず、データ・セキュリティにおける自動化の重要な価値は、脆弱性や悪用の可能性が発生してから、その脆弱性を特定して修正するまでの間隔を短縮できることです。この分野では、遅延が発生するたびに直面するリスクが高まる。タイムギャップを埋めることは、想像以上の価値がある。
さらに、効率という小さな問題もある。BigFixは、ソフトウェアのデプロイ、パッチ管理、設定変更など、ルーチンワークを自動化することで、手作業を大幅に削減し、ITチームはより戦略的な取り組みに集中することができます。
BigFixが自動化するもう一つのポイントは、コンプライアンス・ポリシーの実施です。また、コンプライアンス管理と規制評価を簡素化する監査およびレポート機能も備えています。
NeoVADでは、提供する各製品の利点を強く意識しています。その理由のひとつは、営業チームの採用やトレーニング、リセラー・パートナーとの協働によるソリューションの教育、そして各パートナーとのチャネル構築など、多くの時間と費用を投資し、そのすべてを実現しているからです。
その結果、私たちはソリューション、ベンダー、リセラー・パートナー、そして顧客など、このエコシステムに関わるすべての人々と深く関わり、彼らの成功に深く投資しています。私たちは軽々しく選択することはありませんし、私たちが下す決断のひとつひとつは、実際の現場で厳しくテストされています。ですから、私たちにとって安心への道はBigFixなのです。
というのも、検討すべき機能、性能、ユースケースは何百とあり、その多くがあなたにも当てはまるからです。
しかし、私はシンプルであることを約束した。だから、これだけは言わせてほしい: もしあなたが安心感を求めているのなら、HCL BigFix は正しい方向への大きな一歩です。
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 の詳細については、こちらをご覧ください。