2021/11/18 - 読み終える時間: 7 分

Webhook basics の翻訳版です。

Webhook の基礎知識

2021年11月17日

著者: Mark Zukowsky / Senior Software Architect

はじめに

VersionVault Expressは、プロジェクト内で興味深いイベントが発生した際に、通知を送信するように設定することができます。これらの通知はWebhookと呼ばれます。Webhookは単純に、HTTPでPOSTリクエストとしてエンドポイントに送られるJSONペイロードです。HTTPのPOSTリクエストに応答できるシステムであれば、Webhookのエンドポイントとなり、任意のアクションを実行できます。この記事では、webhookに関連する基本的な情報を見ていきます。webhook定義の作成と更新には、プロジェクト内でビルダーの役割を持つユーザーが必要です。ロールについては、VersionVault Expressブログの「プロジェクト・チーム・メンバーのロール」を参照してください。

プロジェクトとストリームのWebhookの比較

VersionVault Expressでは、ユーザーはプロジェクトまたはプロジェクト内の個々のストリームのいずれかのコンテキストでWebhookを作成することができます。Webhookのトリガーの実装はすべてのWebhookで同じであり、プロジェクトとストリームのWebhookの違いは、どの基本的なイベントがWebhookのトリガーを引き起こすかということです。プロジェクトWebhookの作成は、プロジェクト設定ページのWebhookページで行い、ストリームWebhookの作成は、プライマリ・ストリーム・ページのWebhookページ（ストリームごとに移動）で行います。プロジェクトとストリームのどちらのWebhookを作成する場合でも、最初のWebhookを作成することができます。

Webhook定義画面

Webhookの作成画面は、選択できるイベントを除き、プロジェクトとストリームのWebhookで同じです。

webhookの作成画面は上記の通りです。右上のアクティブ・スライダーは、Webhookがトリガーするかどうかを示しています。webhookの定義を削除せずに、webhookのトリガーを止めたい場合があります。デフォルトでは、Webhookはトリガーします。

Webhook name (Webhook名)

Webhook nameは、Webhookの識別子です。

ペイロードURL

ペイロードURLは、リクエストに応答するエンドポイントの定義です。ペイロードURLは、JSONボディを持つHTTPリクエストを受け取り、ペイロードに基づいて必要なアクションを実行します。

シークレット

シークレットは、ペイロードの内容に基づいたハッシュをWebhookのHTTPヘッダに追加します。

ストリーム Webhook 用のイベントタイプ

Webhookのペイロード

各Webhookには、Webhookのトリガーとなったイベントに役立つさまざまな情報が含まれています。ペイロードの完全な情報については、ブログページ を参照してください。

SSL検証の無効化

デフォルトでは、サーバー証明書は利用可能な認証局に対してチェックされます。このオプションを選択すると、必要に応じて検証がバイパスされます。

Webhookの起動

Webhookが起動すると、HTTPリクエストがエンドポイントに送信されます。 ヘッダーのContent-Typeはapplication/jsonを示します。リクエストのボディはペイロードのJSON表現で、ペイロードの内容が含まれています。ペイロードのサンプルを以下に示します。すべてのWebhookのペイロードに共通するフィールドが含まれています。

Webhookの作成時にシークレットが指定されていた場合は、ペイロードとシークレットのハッシュ値を含む以下のような追加ヘッダーがHTTPリクエストに追加されます。

X-VV-Signature : sha256=866c3800b398bd8c97a575268b2dea7b6adc329a3052ffec140572ed86e61b1f

この署名は、秘密を知っているエンドポイントが再現することで、ペイロードが変更されていないことを確認できます。エンドポイントの設定方法については、VersionVault のブログサイトをご参照ください。

HTTPリクエストを送信すると、sendは指定されたエンドポイントとの接続が確立するまで最大60秒、接続が確立するとエンドポイントからの応答を受信するまで最大20秒待機します。エンドポイントがリクエストに対して意味のある形で応答することが重要です。サーバーは、エンドポイントからの応答に基づいて、以下のように行動します。

• エンドポイントが有効なレスポンスを返信した場合、ヘッダー、ボディ、レスポンスコード、レスポンステキストが取得され、Webhookの配信レコードとして保存されます。この配信記録を取得することで、Webhook配信のステータスを確認できます。

• エンドポイントから返信がない場合や、400シリーズのHTTPコードで返信された場合は、Webhookが再試行されます。この場合、配信記録は失敗の状態で更新され、60秒後に新しいリクエストが再送されます。この再試行サイクルは3回（合計3分）繰り返されます。すべての再試行でWebhookの送信に失敗し、受理されたステータスを受信した場合、このインスタンスのWebhookのトリガーについては、それ以上の再試行は行われません。失敗した試行のステータス情報は、webhookの情報画面から取得できます。

• 決して受信しないエンドポイントが設定されている場合：Webhookのペイロードは4回送信されます。

Webhookの配信記録

各Webhookは、配信試行のステータスの記録を保持します。VersionVault ExpressのUIでこれらの記録を確認すると、エンドポイントへの到達に問題がある場合や、エンドポイントに問題がある場合、あるいはまれに成功した場合などがあります。

まとめ

Webhookは、VersionVault ExpressまたはVersionVault Explorerデスクトップ・クライアントによって開始されたかどうかに関わらず、VersionVaultで発生したさまざまなイベントに基づいてアクションを起こすための強力な方法です。ペイロードを受信して処理するエンドポイントを適切に開発すれば、統合の可能性は無限に広がります。

2021/11/18 - 読み終える時間: ~1 分

Here’s what Secure DevOps looks like in action の翻訳版です。

Secure DevOps の実際の姿をご紹介

2021年11月18日

著者: Elise Yahner / Elise works on marketing strategy and campaigns for HCL Software DevOps.

Secure DevOps、DevSecOps、SecDevOps。これらはすべてソフトウェア開発でよく使われる用語ですが、本質的には同じことを意味しています。つまり、セキュリティは開発業務に不可欠であり、セキュリティをより左にシフトすることができれば、組織はコストと品質の面で有利になるということです。

SDLCの早い段階でセキュリティを追加するのは大変なことのように思えますが、適切なツールと戦略を導入すれば、シームレスに調整することができます。さらに、ガバナンスとリソース管理の改善によるメリットは、セキュアなDevOpsアプローチを取る努力をはるかに上回るものです。

セキュアなDevOpsパイプラインがどのようなものかを具体的に示すために、以下のデモを作成しました。このデモでは、当社の自動テスト、バリュー・ストリーム・マネジメント、継続的デリバリ、およびセキュリティ・スキャンの各ソリューションが、ビジネス・アジリティの問題を解決するためにどのように連携しているかをご覧いただけます。セキュアなDevOpsパイプラインがどのようなものかを具体的に示すために、以下のデモを作成しました。このデモでは、当社の自動テスト、バリュー・ストリーム・マネジメント、継続的デリバリ、およびセキュリティ・スキャン の各ソリューションが、ビジネス・アジリティの問題を解決するためにどのように連携しているかをご覧いただけます。

より詳細なデモをご希望ですか？ swinfo@hcljapan.co.jp までメールでお問い合わせください。

2021/11/17 - 読み終える時間: ~1 分

ニュース: 「2021年11月10日: 2022年度第3四半期にリリースされたHCLのソフトウェア製品について」を公開しました。

HCL Software では引き続き製品開発に投資を行い、エンタープライズでの IT 活用を支えるソフトウェアを提供しています。

2021/11/16 - 読み終える時間: 4 分

5 things marketers can learn from Doom の翻訳版です。

マーケターが Doom から学べる 5 つのこと

2021年11月12日

著者: Catrina Boisson / Marketing & CX Specialist, Unica 共著: Idir Hillali / Director of Innovation at HCL Software

Doomは、没入型ビデオゲームのOGです。 1993年に発売された『Doom』は、このジャンルを実質的に確立しました。30年近くが経過し、20作品が発売され、1,000万本以上の売り上げを記録した今でも、このフランチャイズは多くの人から最高傑作とみなされています。

Doomの人気の秘密は、心理学者が定義する "フロー "を実現していることにあります。"フロー "とは、「ある活動を行っている人が、その活動の過程において、エネルギーに満ちた集中力、完全な関与、楽しみを感じながら、完全に没頭している精神状態」のことです。

しかし、それがマーケティングとどのような関係があるのでしょうか？

私は次のように考えています。

• フロー状態に相当するマーケティングは、昔から言われている「適切なメッセージを、適切なタイミングで、適切な人に、適切なチャネルを介して届ける」ことであり、押しつけではなく、サービスのように感じられるほど適切でシームレスなマーケティングである。
• フロー状態のマーケティングを実現する鍵は、ビデオゲームにあるのかもしれません。

一人称の視点

Doom のような没入型のゲームでは、プレイヤーが主人公となります。 起こることすべてが、プレイヤーの目と視点で展開されます。

最高のマーケティングとは、もはや製品中心でもチャネル中心でもありません。それは、顧客中心であり、経験に基づいたものです。売ることをやめて、顧客が何をしようとしているのか、そのニーズを満たすためにはどうすればいいのかを考えましょう。

選択肢

Doomでは、プレイヤーは無限の選択肢を持っていますが、それらは特定の状況や瞬間に合わせて提示されます。

最高のパーソナライゼーションは、リアルタイムで、文脈に沿った、個別のものです。お客様について知っているすべてのことと、お客様が今していることを組み合わせて、チャンネルに反映させます。

コントロール

Doomをプレイするとき、アクションは自分に起こるだけではなく、自分がアクションを動かしています。 そして、自分が下した決断に基づいて、生きるか死ぬかが決まる...。

GDPR、HIPAA、CCPA、IOS15の世界では、お客様が自分のデータをコントロールします。お客様がデータ収集を許可するのは、お客様がデータをどのように使用するかを信頼する場合のみです。スパムを送ったり、負荷をかけたり、顧客の明確な好みを無視したりしないでください。あなたが彼らを知っていることを示してください。

自動化

Doomのようなゲームの開発には、何千何万という時間がかかります。アクションは楽に感じられるかもしれませんが、それはプログラミングやビジネスルール、機械学習アルゴリズムなどのコードラインによって動かされています。

チャネル間でキャンペーンをつなぎ合わせたり、プラットフォーム間でデータを投げたり、サイロで反応を分析したりしていては、シームレスで適切なオムニチャネル体験を提供できません。自動化と統合が必要であり、理想的には自己学習／最適化の要素も必要となります。

ジャーニー

私たちが話しているのは、最終的なスコアが楽しさの最大の決め手となっていたPongやPacManではありません。Doomをプレイするとき、あなたは時間をかけて進行するストーリーに没頭し、そのストーリーを前進させるアクションに積極的に参加することになります。

今日のマーケティングは、キャンペーンではなく、会話を重視する必要があります。私たちは何年も前からカスタマージャーニーを描いてきましたが、今はそのジャーニーを実際に運用する時です。

私たちはマーケティングプラットフォームのOGかもしれませんが、新しいv12.1.1のリリースでは、リアルタイムパーソナライゼーション、ジャーニーオーケストレーション、キャンペーン最適化のための私たちのソリューションが、世界中の現代のマーケティング組織を支援しています。

フロー・ステート・マーケティングを実現するためには、HCL Unica がお役に立ちます。

2021/11/15 - 読み終える時間: 2 分

Using web hooks to integrate HCL VersionVault Express and HCL Compass の翻訳版です。

HCL VersionVault Express と HCL Compassを統合するための Webhook (ウェブフック) の使用

2021年11月12日

著者: Brett Markowitz / Software Developer

HCL Software が DevOps 分野で提供する最新の製品 HCL VersionVault Express は、Web UI や REST API などを一新して最近発売されました。VersionVault Expressは、VersionVault の基盤をベースにしており、HCLのセキュアなバージョン・コントロールと構成管理ソフトウェアに関するすべての情報を提供するとともに、簡単に立ち上げることができます。

HCL Compass 2.0 は昨年、同様に外観と機能を一新して発売され、その新しいREST APIとWebhook 機能により、VersionVault Express の完璧なコンパニオンとなっています。

その好例が、オープンソースのサンプル統合です。Node-Redで構築され、VersionVault ExpressとCompassを接続する2つのWebhookレシーバーを素早く作成することができました。

この統合に必要なCompass用Webhooksパッケージのインストール方法については、[]をご覧ください。

CompassでFeature、Task、Storyが作成されてユーザーに割り当てられると、VersionVault Expressのそのユーザーのストリームに対応するアクティビティが作成されるというシンプルな統合です。

そして、そのアクティビティがプロジェクトの統合ストリームに配信されると、Compassのレコードが更新され、追加、変更、削除されたファイルのリストがノートとして表示されます。

統合を含むフローを表示するには、GitHubリポジトリから「flowers.json」ファイルを取得し、Node-RedのWebインターフェイスを開きます（Node-Redがデプロイされている場所であれば、例えばhttps://localhost:1880）。

画面右上のハンバーガーメニューから「インポート」→「クリップボード」を選択し、ファイルをブラウズして開きます。

Compass/VVE Integration」という名前のフローがあるはずで、ここですべてが行われます。

SF_Constantsサブフローでは、統合の設定を行います。

ここには "Set Flow Constants "ノードがあり、VersionVault ExpressとCompassのインスタンスに関連する様々なプロパティを設定することができます。これらは非常に簡単なものですが、それぞれの詳細についてはGitHubリポジトリのREADMEをご覧ください。

フローをデプロイして、定数が設定され、Webhookエンドポイントがペイロードをリッスンしていることを確認してください。

次に、2つの「HTTP in」ノードがあることに注目してください。1つは「[POST] /compass」、もう1つは「[POST] /vve」と表示されており、それぞれが表示されている製品からのWebhookペイロードを処理します。

Compassからペイロードが送られてくると、フローはいくつかのことを順に行います。

• VersionVault Expressで認証します。
• レコードが割り当てられたユーザー名と、レコードが追加されたソリューション名を取り出します。
• ソリューション名を使用して、VersionVault Express内のプロジェクトを検索します。
• プロジェクト名とユーザ名から開発ストリームを取得します。
• CompassのレコードIDを名前にして、そのストリームにアクティビティを作成します。

アクティビティを配信すると、VersionVault ExpressのWebhookレシーバーにペイロードが送信され、以下のシーケンスが開始されます。

• CompassとVersionVault Expressで認証します。
• 配信された各アクティビティについて。
  • チェンジセットを取得し、どのファイルが追加、変更、削除されたかを確認します。
  • アクティビティの名前を使って、関連するCompassレコードを修正し、ファイル情報をメモとして追加する。

重要なのは、このサンプルを意図的にシンプルにしたことです。そのために、いくつかの仮定を組み込んでいます。

• VersionVault ExpressとCompassの両方にユーザーが存在し、そのユーザー名は両方で同じであること。
• ユーザーは、1つのプロジェクト内に1つの開発ストリーム（<プロジェクト名>_<ユーザー名>という名前のフォーマット）しか持たず、アクティビティが作成されるのはそのプロジェクトであること。
• VersionVault Expressのプロジェクトは、Compassで使用されているソリューションと一致する必要があります。

VersionVault ExpressとCompassの最新リリースでは、様々なWebhookイベントが利用できるため、単純な通知受信や複数製品間の複雑な統合など、機能拡張が容易に行えます。

2021/11/15 - 読み終える時間: 2 分

Making and recommending baselines in HCL VersionVault Express の翻訳版です。

HCL VersionVault Express でのベースラインの作成と推奨

2021年11月12日

著者: Margaret Marynowski / HCL Software

この記事では、HCL VersionVault Expressを使用して、Unified Change Managementのベースラインを作成し、推奨する方法を説明します。これらの操作を行うには、VersionVault ExpressのBuilderロールが必要です。(VersionVault Express のロールの詳細については、HCL VersionVault Express におけるプロジェクト・チーム・メンバーの役割 を参照してください)。

UCM ベースラインの基本

ベースラインは、プロジェクト内の各ディレクトリやファイルのバージョンを指定し、任意の時点でのプロジェク トのスナップショットを表します。通常、ビルダーは、ビルドやテストが成功した後など、コードベースが良好な状態にあることがわかっているときにベースラインを作成する責任があります。ベースラインには、プロジェクト内のすべてのディレクトリとファイルを明示的にマークするフルベースラインと、前回のベースライン作成後に変更されたディレクトリやファイルのバージョンのみをマークするインクリメンタルベースラインの2種類が用意されています。インクリメンタル ベースラインを作成する方が速い場合もありますが、開発者はフル ベースラインからアクティビティのチェンジセットを確認する方がパフォーマンスが高い場合もあります。

ベースラインの作成

ストリームにベースラインを作成するには、ビルダーとしてそのストリームのページに行き、「新規ベースライン」ボタンをクリックします。新しいベースラインの名前を入力する必要があり、オプションで説明を入力することもできます。その後、「Incremental」または「Full」を選択し、「Create」をクリックします。

ベースラインの推奨

ベースラインを作成したら、それを推奨することができます。ストリームの推奨ベースラインは、既存の子ストリームのリベース処理のデフォルト選択となり、新しい子ストリームの基礎ベースラインにもなります。基本ベースラインは、ストリームのプロジェクトの現在の既知の状態を表します。新しい子ストリームは、その親ストリームの推奨ベースラインを基礎とします。ストリームをリベースすると、そのベースラインはリベースの際に使用されたベースラインに設定されます。(詳細は、「VVコンセプトの紹介ブログ」を参照してください。)

ベースラインを推奨するには、ビルダーとしてストリームのページにアクセスし、推奨したいベースライン名の左にある下向き矢印（↓*）をクリックします。

まとめ

VersionVault Expressのmake baselineおよびrecommend baseline操作により、開発者はプロジェクトの共通のスナップショットを作業の出発点として使用することができます。詳しくは、ブログサイトをご覧ください。

2021/11/15 - 読み終える時間: 3 分

AppScan is Re-imagining application security with V.10.0.6 の翻訳版です。

HCL AppScan V.10.0.6 による信頼性の高いアプリケーション・セキュリティ・テスト

2021年11月12日

著者: Orlando Villanueva / Product Marketing Manager, AppScan

HCL AppScan V10.0.6は、開発ライフサイクルの各段階でアプリケーション・セキュリティを提供することの意味を再考します。広範なサポート言語のポートフォリオや、SAST製品では複数のIDEプラットフォームをカバーすることで開発者を支援し、AppScan Standardソリューションではアップグレードによりユーザーエクスペリエンスを向上させます。さらに、この最新バージョンでは、新しいセキュリティアップデート、レポートオプション、法規制コンプライアンスレポート用の新しいサマリーセクションを提供します。

このブログでは、AppScan V.10.0.6の新機能と改良点を製品ライン別にご紹介します。また、スペシャルイベント「AppScan Lunch n' Learn」では、以下に紹介する多くの新機能についての詳細をご紹介していますので、ぜひご覧ください。

HCL AppScan Enterprise V10.0.6の機能強化について

AppScan Enterprise V10.0.6では、以下の点が強化されています。

• Subject Alternative Name (SAN)属性を持つクライアント証明書を使用したCommon Access Card (CAC)認証の改善がサポートされました。
• 法規制コンプライアンスレポートには、コンプライアンスと監査のニーズに役立つように設計された新しいサマリーセクションが追加されました。
• Microsoft Active Directory Federation Services (ADFS)によるSAML (Security Assertion Markup Language)シングルサインオンがサポートされました。
• ジョブズ検索APIは、管理者以外のユーザーでもアクセスできるようになりました。

AppScan Enterpriseの機能強化についての詳細は、カスタマーサポートページをご覧ください。

HCL AppScan Source V10.0.6の強化点

AppScan SourceのV10.0.6では、以下の点が強化されています。

• 新たに対応したIDEプラットフォームを提供します。IntelliJ、PHP Storm、WebStorm、PyCharm サポート。
• Dart言語のサポート
• Java、.Net、C/C++のソースコードスキャン（DevOpsのスピードに合わせたスキャン）。
• 業界標準のレポートによる修復情報の提供
• Visual Studioの修正グループ
• SASTの新しいアプローチのための技術プレビュー

AppScan Enterpriseの機能強化についての詳細は、カスタマーサポートページをご覧ください。

HCL AppScan Standard V10.0.6の強化点

AppScan StandardのV10.0.6では、以下のような機能強化が行われています。

• 新しいAppScanエクスペリエンスが登場します。新しいAppScan Standardの技術プレビューコード版を用意しました。大幅に改善されたユーザーエクスペリエンスと、同じ強力なDASTスキャンエンジンを備えています。これはまだ進化中のバージョンであり、今後のリリースを通じてゆっくりと段階的に進化していきます。詳細を知りたい方、今すぐ無料体験したい方は ここをクリック。
• レポート（XML、PDF、HTML、Word）は、ユーザーインターフェースと同じ一般的なコンテンツと構造を持つようになりました。
• 法規制コンプライアンスレポートでは、コンプライアンスや監査のニーズに役立つように設計された新しいサマリーセクションを提供しています。

AppScan Enterpriseの機能強化に関する詳細は、カスタマーサポートページをご覧ください。

特別イベント「AppScan Lunch n' Learn」のご案内と詳細について

上記の機能強化についての詳細は、「AppScan Lunch n' Learn」スペシャルイベントをご覧ください。

AppScanの最新の開発状況については、YouTubeの「This is AppScan」チャンネルをご覧ください。

2021/11/15 - 読み終える時間: ~1 分

An overview of activities の翻訳版です。

アクティビティの概要

2021年11月12日

著者: Edward dunlop / Edward is a software engineer at HCL Software who played a key role in developing the HCL Compass and HCL VersionVault Express UI’s.

l

HCL VersionVault Express の最新リリースでは、UCM（Unified Change Management）プロジェクトの開始がこれまで以上に簡単になりました。UCMプロジェクトの開発ライフサイクルにおいて、開発者はストーリーの実装や不具合の修正などのタスクを完了させる必要があります。アクティビティは、タスクが完了するまでの進捗状況を追跡します。タスクのためのアクティビティを作成し、そのアクティビティをストリームに設定するだけで、ストリームに加えられた変更はすべてそのアクティビティによって追跡されます。

バージョンコントロール下のファイルに変更を加える前に、アクティビティを設定する必要があります。アクティビティは、各ストリームのページの右上にある「新規アクティビティ」ボタンで作成できます。アクティビティが作成されると、ボタンの横にあるドロップダウンを使って設定できます。折りたたまれたドロップダウンには、現在のアクティビティのタイトルが常に表示されるので、開発者はどのアクティビティを変更しているのかを常に把握できます。

アクティビティを設定した後、開発者はストリーム内のファイルやフォルダの変更を開始できます。開発者が別のタスクに焦点を移したい場合は、何をしていても簡単に新しいアクティビティを作成または設定できます。バージョンコントロールにチェックインされたすべての変更は、設定されたアクティビティによって追跡され、そのアクティビティのチェンジセットに表示されます。

ストリームのページでアクティビティタブに切り替えると、開発者は各アクティビティの下で行われたすべての変更を確認できます。アクティビティの[Review]ボタンをクリックすると、そのアクティビティが設定されている間に変更されたすべてのファイルやフォルダが表示されます。リスト内の項目を展開すると、その項目の現在の状態と、アクティビティが作成されたときの状態（チェンジセットプリデレクタとも呼ばれる）が比較されます。開発者がコードを配信する際には、各アクティビティで変更された内容を正確に確認し、どのアクティビティを配信するかを選択できます。

開発者がある要素の特定のバージョンを確認したい場合は、アクティビティ リストのアクティビティをクリックします。アクティビティが展開され、開発者はそのアクティビティのチェンジセットを見られます。チェンジセットの各エントリは、選択したアクティビティで変更されたファイルやフォルダの異なるバージョンを表します。開発者は、チェンジセット内のファイルをクリックすると、そのバージョンのファイルを見られます。また、ファイルの任意のバージョンを、その直前のバージョンやチェンジセットの前のバージョンと比較できます。これは、開発者がレビューしたいアイテムの[Compare With]ドロップダウンを使用して行えます。

アクティビティ] タブでは、設定されたアクティビティが常に他のアクティビティの上に表示されます。アクティビティの設定や削除も、ここから行うことができます。

詳細はこちらのドキュメントをご覧ください。