2020/9/22 - 読み終える時間: 4 分

Identify the best offer for treatment rules using A/B Testing in Interact の翻訳版です。

HCL Unica Interact の A/B テストを使用して、トリートメントルールに最適なオファーを識別する

2020年9月21日

著者: Gurpreet Singh / Test Lead for HCL Interact

復習: A/B テストとは何か？

私たちのようなマーケターがランディングページを作成したり、メールのコピーを書いたり、コールトゥアクションボタンをデザインしたりするとき、何が人々をクリックさせ、コンバージョンさせるかを直感で予測したくなることがあります。

しかし、「感覚」に基づいてマーケティングの決定を下すことは、結果にかなり悪影響を及ぼす可能性があります。推測や思い込みに頼るよりも、A/B テスト（スプリットテストと呼ばれることもある）を実施した方がはるかに良い結果が得られます。

A/B テストは、同じシナリオの 2 つのバージョンを1つのパラメータを変えて比較するプロセスです。

オーディエンスの行動が異なるため、A/B テストは価値あるものとなります。

Interact における A/B テストの仕組み

HCL Unica Interact では、A/B テストとは、すべてのプロパティが固定されているが、1つのパラメータだけが変化する処理ルールに対して行われるテストのことです。ルールのA/B テストでは、変化する各パラメータは、オーディエンスの分配率を持つ1つのブランチを表します。

設定されたテスト期間内のオファーに対するオーディエンスの反応に応じて、マーケッターはその処理ルールに最適なオファーを選択することができます。

トリートメントルールの A/B テストの設定

• 新しいオプションA/Bがルールメニューに追加され、それを使用することで、マーケッターは直接A/B テストペインに行き着くことができます。

• A/B テストタブで、マーケッターは有効チェックボックスを選択することで、ルールのA/B テストを有効にすることができます。
• ルールのA/B テストを有効にすると、ベースルールから詳細をコピーしてデフォルトブランチが追加されます。

• マーケターは「ブランチの追加」をクリックして、より多くのブランチを追加することができます。

• A/B テスト内で一意にすべきブランチ名をマーケターが変更できる。

• ブランチは有効と無効を切り替えることができます。有効なブランチのみが実行時に A/B テストに参加します。

• サンプリング%は、ブランチ間のオーディエンスの分布です。

• オファー属性に式を追加すると、そのカウントが「オファー属性」列に表示され、詳細を確認するためのドロップダウンが表示されます。

• マーケターは、A/B テストを有効にする「テスト期間」を設定することもできます。

• デフォルトブランチとは、A/B テストブランチから分岐したブランチのことで、テストが終了すると、つまり有効期限が切れた後に実行されます。デフォルトブランチは、セルコード、オファー、パラメトリック化されたオファー属性のベースルールから完全に独立しています。12.1リリースでは、マーケターはデフォルトブランチを指定する必要があり、常に有効にしておく必要があります。今後のリリースでは、デフォルトブランチの選択は、ブランチのパフォーマンスに応じて自動的に行われるようになります。

• ルールリストページでA/B テストの詳細を保存すると、ルールに対してオレンジ色の「A/B テスト」アイコンが表示されます。

• ルールリストの編集または表示モードで「A/B テストルールのみを表示する」チェックボックスを選択すると、A/B テストルールのみをフィルタリングすることができます。

• 「A/B テストルールのみ表示」を有効にすると、限られたカラムのセットが表示され、セクションを拡張することで、サンプリング％やオファー属性の数などの分岐の詳細を式で確認できます。

• また、「A/B テストのルールのみを表示」フィルタを使用して、セグメントやゾーンによる検索を使用してルールをさらにフィルタリングすることができます。
• A/B テスト付きインタラクティブチャンネルがデプロイされると、デプロイ Info.jsp にルールのA/B テストの詳細が表示されます。

• システムテーブルにA/B テストデータを保存するために、デザインタイム（キャンペーン）スキーマ UACI_ABTest と UACI_ABTestBranch に2つの新しいテーブルが追加されました。

A/B テスト結果の分析

マーケターは、以下の方法でブランチのパフォーマンスを分析し、そのブランチのオファーを処理ルールのデフォルトオファーとして設定できます。

• ブランチのパフォーマンスをチェックするには、ターゲットのCHStagingとDTLContactHistテーブルに文字列データ型のカラム "ABTestBranch "を追加する必要があり、その後、顧客はクエリを実行したり、ブランチのパフォーマンスを決定し、ルールのためのデフォルトブランチを設定するカスタムレポートを作成することができます。
• 顧客は、CognosまたはBirtレポートを設定し、「Interactive Offer Performance Over Time」レポートをチェックして、オファーパフォーマンスのサマリーを確認し、どのブランチオファーがうまくいっているかを判断できます。

2020/9/22 - 読み終える時間: 2 分

Maximize your BigFix Return on Investment with AVP の翻訳版です。

AVP で BigFix の投資収益率を最大化する

2020年9月21日

著者: John Riddle / Senior Manager ? Services

HCL BigFix ソリューションへの投資は、環境を効果的に展開し管理するためのスキルを社内に持っていなければ、大きく前進することはありません。また、最新の製品強化、ベストプラクティス、そして何よりもITインフラに影響を与え、停電を引き起こす可能性のあるセキュリティ上の脅威やマルウェアを常に把握しておく必要があります。

HCL Software Accelerated Value Program (AVP)は、技術的なリソースにすぐにアクセスできるようにすることで、BigFix ソフトウェアへの投資に対するリターンの価値を最大限に高めることができるように支援する技術的なアドバイザリー・サービスです。

この最高のサービスは、お客様の短期的なニーズと長期的な計画に合わせて調整された対応するサービス成果物のセットを提供する、事前にパッケージ化された年間契約です。お客様には、BigFix 専任エンジニア（ BDE ）が割り当てられ、お客様のチームと協力して、セキュリティとエンドポイント管理の目標と目的を達成する包括的な計画を開発します。BDE は複数の役割を担っています。

• BigFix の窓口となり、信頼できるアドバイザーとして、すべての HCL グループとチーム間のコミュニケーションの推進
• BigFix のエンジニアリングチームとオペレーションチームのバーチャルチームメンバーになります
• BigFix 製品のあらゆる面で BigFix の経験とスキルの提供
• 新規プロジェクトをサポートするための BigFix の簡単な実装
• BigFix のさらなる展開と採用のための障壁を取り除く支援
• BigFix 環境のアーキテクチャの確認
• 包括的な年1回の健康診断の提供
• トレーニングを提供し、BigFix の技術専門家やリソースへのアクセスを提供することによる、スタッフのスキルの向上

• 期待される内容

BDE は、以下のように努力します。

• 目標の理解。BDE は、BigFix のニーズを理解し、ロードマップ、現在の課題などを確認するために、チームとのミーティングを何度か開催します。
• 計画の策定。最初の 30 日間に、BDE は、次の 12 ヶ月間の期待に応えるためにカスタマイズされた計画を作成します。
• 毎週または隔週でプロジェクト会議を開催し、目標、問題点、問題点、およびプロジェクトを検討します。
• 成功を評価します。私たちはあなたの成功をサポートすることに専念しています。私たちの目標は、BigFix の健全性がお客様に満足していただけるようにすることです。評価と報告は、ご要望に応じて提供されます。

主な成果物

AVP は以下を提供します。

• 積極的なアカウント管理とCASE管理計画。
• 製品に関する質問、製品の使用計画、およびサポート問題に関する技術的な支援。
• 移行、アップグレード、新機能の実装に関するアドバイザリー支援
• BigFix のベストプラクティス
• セキュリティの脅威とHCL製品の脆弱性に関する積極的な通知。
• 診断およびトラブルシューティング技術に関するコーチング。
• 優先度の高い問題については、毎月の技術的な対話を行います。
• 制限されたイベント（製品ロードマップ、製品説明会、エグゼクティブ・カンバセーション）へのアクセス。
• 修正プログラム、技術文書、制限されたコードへのアクセス。
• BETAおよびアーリーアダプター（EA）プログラムへの自動招待。

価格設定

AVP の提供は年間契約です。価格は、BDE の割り当てられたコスト、BDE があなたの組織内でインターフェイスする連絡先の数、および予想される出張に基づいています。

メリット

BigFix Accelerated Value Program を利用することで、技術支援や製品の開発を可能にするHCLの専門家リソースへのアクセスが可能になり、BigFix の導入や統合の成功率が向上し、移行の計画が立てやすくなります。さらに、AVP は、技術的なソフトウェアの問題を診断して解決する際の社内スタッフの専門知識と習熟度を高め、脅威に関する高度な警告によりセキュリティ侵害を回避し、セキュリティリスクと予期せぬダウンタイムを最小限に抑え、価値を生み出すまでの時間を短縮し、BigFix への投資のROIを最大化することができます。

BigFix Accelerated Value Program の詳細については、john.riddle@hcl.com まで電子メールでお問い合わせください。BigFix の詳細については、www.bigfix.com をご覧ください。

2020/9/19 - 読み終える時間: ~1 分

BigFix Lifecycle and Compliance now includes MCM and Insights の翻訳版です。

BigFix Lifecycle と BigFix Compliance に MCM と Insights の使用権が追加

2020年9月19日

著者: Cyril Englert / Solution Architect

2020年9月17日より、すべてのアクティブな BigFix Lifecycle と BigFix Compliance のお客様は、BigFix Modern Client Management (MCM) および BigFix Insights を利用する権利を得られます。これらの権利は、お客様の投資に対するビジネス価値を拡大させます。

BigFix Insights は、BigFix管理者およびエンタープライズ・データ・アナリスト向けに設計されたデータ分析プラットフォームで、BigFixのデータとサードパーティのソリューションのデータを組み合わせることができます。BigFix Insightsは、高度な自動化、合理化された相関関係、および企業の高度な洞察を提供します。詳細については、https://www.hcltechsw.com/wps/portal/products/bigfix/offerings/insights15 をご覧ください。

BigFix Modern Client Management ((MCM) は、複数のベンダーを統合し、シンプルな登録とポリシー管理で Windows 10 と macOS デバイスを管理しながら、コストと複雑さを軽減することを実現ます。詳細については、https://www.hcltechsw.com/wps/portal/products/bigfix/offerings/client-management12 をご覧ください。

BigFix チームは、お客様に価値を提供し続けるために努力しており、今回の発表は BigFix の ROI を飛躍的に向上させるものです。 ご質問がある場合は、BigFix のスペシャリストまたはテクニカル・アドバイザーまでお問い合わせください。

2020/9/19 - 読み終える時間: 7 分

Introduction to FlexOffers in Unica Interact の翻訳版です。

HCL Unica Interact の FlexOffers の紹介

2020年9月19日

著者: Shilpa Dhabale / Technical Specialist, Unica Interact

マーケティングの流れは、コールドコールからリアルなコミュニケーションへと変化し、コミュニケーションのチャネルやモードに関係なく、リアルタイムで顧客とのエンゲージメントを図るようになりました。Unica Interact は、コールセンターなどの顧客対応システムと統合し、リアルタイムでパーソナライズされたオファーを送信することで、インタラクティブで充実した顧客体験を提供できます。FlexOffers はそのような Interact のコンポーネントの一つで、企業のオファー、顧客プロファイル、顧客のリアルタイムのアクティビティデータを Windows のスプレッドシートにマッピングし、マッピングテーブルのような形で表示できます。

それは何ですか？

マーケティング担当者は、プロファイル属性に関するいくつかの条件のみを使用してセグメンテーション・ロジックを設計します。このようなルールの多くは、ソート、検索、フィルターなど、スプレッドシート・ソフトウェアに備わっている豊富な機能を活用することを可能にしています。また、頻繁な更新が必要なルールもありますが、FlexOffers を利用することで、簡単に更新できます。

どのように役立ちますか？

FlexOffers はマーケターが最適な顧客にオファーを簡単にマッピングするのに役立ちます。マーケターは、基本的なマッピングデータを入力したCSVファイルを利用して、システムにインポートし、オファー、ゾーン、セルなどのシステムデータと統合することで、FlexOfferのマッピングテーブルを作成できます。これまでのように、インタラクティブチャネルを展開するためには、インタラクティブフローチャートやインタラクション戦略は必要ありません。プロファイルテーブルをマッピングし、FlexOffers マッピングを作成し、ICをデプロイするだけです。

FlexOffers はどのように動作するのでしょうか？

FlexOffers を利用するために必要な基本的なステップは以下の通りです。

• マッピングの作成(既存のテーブル、.csv、新規テーブル)
• ルールの追加/編集/更新
• ルールのカスタマイズ
• フィルタの作成
• マッピングテーブルを profileServerGroup にコピーします。
• IC の配置

1. FlexOffers マッピングの作成

FlexOffers のマッピングは3つの方法で作成できます。

• 既存のテーブルを使用してマッピングを作成します。
• .csvを選択します。

新しいテーブルを作成し、そのテーブルにルールを追加します。

リスト ページのソース列は、FlexOffers マッピングが作成されたソースを示します。.csv から入力を選択する際には、いくつかの重要な注意点があります。

• カンマ区切りの .csv ファイルのみサポートされています。
• OfferID列は必須フィールドです。
• .csvファイルからの入力は再インポート可能です。

2. FlexOffers ルールの作成

3番目のオプションを使用してマッピングを作成します。New Input/Source テーブルを作成します。ルール] タブで、[オファーの追加/編集] をクリックします。

2.1 新しいルール/基準の追加

• Add Rules]を選択して新しいルールを追加します。

新しいルールが追加されると、セルコード列にデフォルトセルの値が追加されます。

• Default cell]: 選択した場合、Affinium|Campaign|partitions||Interact|whiteList||offersBySQL:defaultCellCodeでセルコードが指定されていることを確認してください。
• 新規セル]を選択すると、このルールを保存している間に新しいターゲットセルが作成されます。

2.2 詳細オプションを使用してルールをカスタマイズする

各オファールールは、高度なオプションの機能を使用してカスタマイズすることができます。例えば、適格性とスコアの述語の設定、学習モデルの適用、オファー属性のパラメータ化などです。

オファーの適格性

オファーの適格性は、ルールが有効になっている場合でも、オファーが適格かどうかを判断するために使用されます。オファーが有効期間（有効日と有効期限の間）に該当する場合、または実行時に式が真と評価される場合、オファーは適格です。ルールの詳細オプションアイコンをクリックすると、オファーの適格性に移動します。

マーケッターのスコア

すべてのルールには、デフォルトのマーケタースコアが割り当てられています。マーケター・スコアは、静的な値を持つこともできますが、オファー属性の式を使用して指定できます。この指定された式は、Interact 実行時にマーケター・スコアを計算するために使用されます。静的な値を持つか、述語を使用して各マッピングのスコアを設定します。

オファーのパラメトリック化と学習モデルの適用

オファーのパラメトリックなオファー属性は FlexOffers ルールで指定することができます。また、学習モデルを適用して実行時に提案されたオファーに影響を与えることができます。オファーパラメータの値を編集します。

オファーの学習モードと学習モデルの編集

2.3 ルールの追加、編集、削除、更新

追加、編集、削除、コピーのような異なるアクションは、一度に単一または複数のルールで実行することができます。

新しい基準(カラム)の追加

インラインでの単一/複数のルールの編集

ルールに必要なすべての変更を行ったら、ルールを保存します。

4. FlexOffers を検索

検索機能は、編集モードと表示モードの両方で利用可能で、異なる属性に基づいて特定のオファーを検索するのに役立ちます。

5. フィルタの作成

フィルタは、ターゲット顧客のための希望のオファーを得るために作成され、ルールに適用されます。各フィルターは、マッピングテーブルのルール属性/フィールドに条件を持っています。フィルターの値は、一定の値か、定義済みのリアルタイム属性とマッピングされたプロファイルテーブル属性のリストから選択されます。フィルター条件を満たすオファーのみが顧客に提示される。複数の条件を同じフィルターに追加して、希望のオファーを得ることができます。また、1つのOfferMappingに複数のフィルタも作成できます。

例えば、OfferName に Retention を含むフィルタを作成します。

6. FlexOfferMappingをサーバーグループにコピーする

インタラクティブ チャンネルをデプロイする前に、FlexOffer マッピング テーブルを profileServerGroup にコピーする必要があります。FlexOffers マッピング リスト ページから、必要なマッピングを選択し、選択したサーバー グループにコピーします。

マッピングが serverGroup にコピーされたら、マッピングを展開用にマークして、インタラクティブ チャンネルを展開します。

7. インターアクト ランタイム プロセス 対象となるフィルタ

Interact ランタイムからオファーを取得する際には、以下のロジックに従ってフィルタが適用されます。

UACIEnableOfferMappingFilter - フィルタがデフォルトではなく、ユーザがフィルタの適用を希望する場合は、startSession または getOffers の際にフィルタ名と一緒にパラメータを送信する必要があります。デフォルトとしてマークされているフィルタは、必ずしも明示的にパラメータを渡す必要はありません。

UACIDisableOfferMappingFilter - デフォルトとしてマークされているフィルタを適用したくない場合は、startSession または getOffers の際にフィルタ名と一緒にパラメータを送信しなければなりません。

フィルタ条件を満たすオファー保持のみが返されます。

スキーマの変更

以下のテーブルは、FlexOffers 機能をサポートするために Interact Design time に追加されます。

• UACI_OfferMappingSG - このテーブルには、すべての FlexOffers と FlexOffers ルールテーブルがコピーされたサーバーグループの情報が含まれています。
• UACI_OfferMapping - FlexOffers ルールテーブルのサンプルテーブルであり、データは含まれていません。
• UACI_OfferMappingList - このテーブルには、FlexOffers のマッピング情報が含まれています。
• UACI_OfferMappingFilter - このテーブルには、FlexOffers で利用可能なすべてのフィルタの情報が含まれています。
• UACI_DepOfferMappingQueue - このテーブルは、デプロイ用にマークされた FlexOffer オブジェクトを保持するステージングテーブルとして機能します。FlexOfferは、デプロイのためにマークされると、レコードが挿入されます。IC がデプロイされると、レコードはこのテーブルから削除されます。
• UACI_DepOfferMappingList - このテーブルには、配備されたすべての FlexOffer のすべての情報が含まれています。インタラクティブチャネルがデプロイされると、レコードがこのテーブルに追加されます。このテーブルは、FlexOffers を持つ同じ IC をデプロイする際に、デプロイアクションによって参照される重要なテーブルです。

参照すべきログ

• 実行時のログはInteract.logに書き込まれます。
• 設計時間のログは campaignweb.log に書き込まれます。

アップグレードの影響

アップグレード後、FlexOffers タブがすべてのICで利用可能になります。変更は Design-time アップグレードスクリプトの実行後に行われます。

スプレッドシート機能を利用して頻繁に更新が必要なルールは、FlexOffers を利用して実現できます。マーケティング担当者は、マッピングテーブルをランタイムインタラクトノードに簡単にコピーでき、マッピングフィルタを作成してからデプロイも可能です。FlexOffers の詳細については、弊社までお問い合わせください。

2020/9/19 - 読み終える時間: 6 分

Organizing Web Application Deployment in HCL ZIETrans の翻訳版です。

HCL Z and I Emulator for Transformation: Web アプリケーションデプロイメントを組み上げる

2020年9月17日

著者: Akshata Betageri / Developer, Lab Services, HCL ZIE

HCL ZIETrans は、3270 および 5250 端末アプリケーションをウェブ、ポートレット、リッチクライアント、または標準 SOAP または RESTful ウェブサービスとして拡張することで、ユーザーエクスペリエンスを変革することができます。デフォルトでは、すべての HCL ZIETrans Web アプリケーションは、1 つのエンタープライズ・アーカイブ・ファイルに保存されます。

HCL ZIETrans Toolkitは、新しいアプリケーションの開発を可能にするHCL ZIEコンポーネントであり、各変更をプレビューして保存することができます。HCL ZIETrans アプリケーションが提示するデータや機能を持つホストアプリケーションをより使いやすくするように、HCL ZIETrans アプリケーションを合理化することができます。複数の HCL ZIETrans アプリケーションを1つの ear で利用するための対応サーバは、「WebSphere Application Server」と「WebSphere Liberty」です。

本ブログでは、プロジェクト内に複数の.earと複数の.warを持つ HCL ZIETrans Webアプリケーションを HCL ZIETrans Toolkitを使って管理する方法とベストプラクティスを紹介します。

アプリケーションを HCL ZIETrans EAR ファイルとしてエクスポートし、WebSphere Application Server にデプロイすると、.ear ファイルには、各アプリケーションを実行するためのリソースを含む Web アーカイブ (.war) ファイルが含まれます。EAR は、複数の Web プロジェクト (WAR)、Enterprise JavaBeans プロジェクト (JAR)、標準 JAR などを 1 つのアプリケーションに結合することもできます。

個々の.earは、実行時に約25MB(最小)のディスクスペースを消費します。したがって、複数の HCL ZIETrans プロジェクトを持っている場合、アプリケーションの複雑さに応じてサイズの異なる複数の HCL ZIETrans EARを持つことになるかもしれません。異なる展開または開発シナリオに基づいて、開発者／管理者は、単一のEARまたは複数のEARの展開ソリューションを選択することになるかもしれません。

下の表は、「個別」対「単一の複数のwar」のEAR展開方法の特徴的なポイントを示しており、これらに基づいて HCL ZIETrans アプリケーションの展開アーキテクチャを決定することができます。

表 1: 単一の EAR 展開における「個別」対「複数のwar」の比較

HCL ZIETrans ウェブアプリケーションを整理する方法

複数の .war または HCL ZIETrans プロジェクトを 1 つの .ear に関連付け、関連付けを解除するには、EAR の META-INF フォルダにあるデプロイメント記述子 application.xml を使用します。

以下のセクションでは、以下のように説明します。

• HCL ZIETrans Toolkit上でプロジェクトごとに個別の.earを作成します。
• application.xml で複数の.warを1つの.earに追加する
• application.xml 内の.earから.warを削除してデプロイする。

プロジェクトごとに個別の.earを作成する

• File->New->ZIETrans Projectに移動します。プロジェクトの作成コンソールで、プロジェクトの名前を指定します。
• 図のように作成するエンタープライズアプリケーションプロジェクト（.ear）。
• 次へ」をクリックし、接続設定を指定します。完了をクリックします。

ソーシャルメディア投稿のスクリーンショットDescriptionが自動生成されます。

図1：プロジェクトの作成

ナビゲーターには、作成されたプロジェクトとEARが表示されます。

図2: 作成されたプロジェクト

デフォルトでは、すべての HCL ZIETrans ウェブアプリケーションは、既存のエンタープライズアーカイブファイルに関連付けられています。したがって、次のプロジェクトは、上記の ZIETrans_testOne_EAR と同じ .ear という名前になります。このまま使い続けることもできます。

あるいは、ステップ1: 'プロジェクトの作成'ダイアログで別の.ear名を指定して、個々のプロジェクト用に別の.earを作成することもできます。

図3: 個々のプロジェクト用の.ear

各 earを作成し、サーバーにデプロイした後

図4: サーバ上に配置された各 ear

application.xml で複数の.warを1つの.earに追加する

初期状態では、ワークスペースには 4 つのプロジェクトがあります。ここでは、プロジェクト "testFour" がフォルダとしてワークスペースにインポートされます。

図 5: ワークスペースのプロジェクト

1. 例えば ZIETrans_testThree_EAR のように、.war ファイルを追加したいプロジェクトの ear を取ります。META-INF フォルダを展開して application.xml を見つけ、ダブルクリックしてエディタを開きます。

図 6: デプロイメント記述子エディタ

ZIETrans_testThree_EARで見たように、Overview セクションにはすでに "testThree.war "が存在しています。これに他の2つの.warを追加してみましょう。例えば、testFourとtestOneです。

2. .warを追加するには、Overview の右側に表示されているAddボタンをクリックします。Add Itemウィンドウが表示されます。ModuleをクリックしてOKをクリックします。

図7: Add Itemウィンドウ

3. 次のウィンドウには、ワークスペースで利用可能なモジュール/プロジェクトが表示されます。これらのモジュールを 1 つずつ追加します。モジュールを選択し、[完了] をクリックします。application.xml を保存します。

図 8: モジュールの追加

概要ウィンドウは以下のように表示されます。

図 9：概要ウィンドウ

4. サーバとサーバ上に ear をデプロイします。

図10：サーバー上に ear をデプロイする

application.xml の.earから.warを削除する

• 例えば、ZIETrans_testThree_EARのように、.warファイルを削除したいプロジェクトの ear を選択します。META-INFフォルダを展開し、application.xml を見つけます。ダブルクリックしてエディタを開きます。

図 11: .war ファイルの削除

2. ZIETrans_testThree_EARからtestOne.warを削除してみましょう。概要欄のtestOne.warをクリックし、右側に表示されている削除ボタンをクリックします。application.xml を保存します。

削除後の Overview セクションは以下のように表示されます。

3. サーバーに ear をデプロイし、サーバを再起動します。

図12: サーバ上に ear を配置する

お問い合わせ

HCL ZIETrans での Web アプリケーションの整理、自動化機能、Lab サービスの提供に関する詳細については、以下までお問い合わせください。

2020/9/16 - 読み終える時間: 2 分

2020年9月16日、「HCL BigFix Service Graph Connector for ServiceNow の発表 (2020年9月16日)」のニュースリリースをだしましたが、それについての記事 ServiceNowc ServiceGraph Connector for BigFix is now available! の翻訳版を掲載します。

ServiceNowc ServiceGraph Connector for BigFix の提供開始

2020年9月16日

著者: Cyril Englert / Solution Architect

本日、HCL BigFix と ServiceNow は、ServiceNowc ServiceGraph Connector for BigFix の提供開始を発表しました。コネクタは、BigFix の広範でほぼリアルタイムのエンドポイントと資産データを活用して、組織がハードウェアとソフトウェア資産を発見、追跡、理解するのを支援し、ServiceNow の構成管理データベース (CMDB) と連携、格納させます。

コネクタは、BigFix Inventory を活用して、タイプ、場所、接続に関係なく、すべてのエンドポイントに対して単一の費用対効果の高いディスカバリ・ソリューションを提供します。90 以上の異なるオペレーティングシステムをサポートし、BigFix Inventory は、オンプレミス、クラウドまたはハイブリッドクラウド、VPN 接続、または自宅にあるエンドポイントから正確で最新の情報を提供します。ハードウェアとソフトウェアの検出とServiceNow の CMDB との同期を自動化することで、組織は、手動プロセス、不整合性、不完全な資産データを排除し、ServiceNow CMDB に依存しているユーザーに高品質の情報を提供することができます。

BigFix 用 ServiceNowc ServiceGraph Connector のデータフローを以下に示します。

BigFix ServiceGraph Connector は重要なビジネス価値を提供します。インシデント・レスポンス時間を短縮し、エラーやデータの不正確さを減らし、脆弱性への対応を改善し、問題解決時間を短縮します。BigFix ServiceGraph Connector は、BigFix と ServiceNow の両方への投資収益率を向上させます。

BigFix ServiceGraph Connector は無料で ServiceNow アプリストアからダウンロードできます。

Connectorの詳細については、https://hcltechsw.com/wps/portal/products/bigfix/tech-partners/servicenow/servicegraph にアクセスし、2020年10月8日に予定されているウェビナー「BigFix で ServiceNow を強化する」の登録をしてください。

BigFix の詳細については、www.bigfix.com を参照してください。

2020/9/16 - 読み終える時間: 7 分

第一回目の記事「HCL Accelerate: GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management」の第二回目、HCL Accelerate VSM with Jenkins – Part 2 の翻訳版です。

HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 2

2020年9月16日

著者: Daniel Trowbridge / Technical Lead

このチュートリアルでは、HCL Accelerate パイプラインからパラメトリックなJenkinsジョブを設定してデプロイする方法を説明します。

前提条件

• HCL Accelerate との Jenkins 統合の完了
• HCL Accelerate VSM を Jenkins と組み合わせて使用する - パート 1 の完了
• GitHub と Jira と組み合わせた HCL Accelerate Value Stream Management の完了を推奨しますが、必須ではありません。

1. PRODデプロイ用のJenkinsジョブを作成する

1.1 新しいパイプラインジョブの作成

今回は架空のプロダクションまたは「PROD」環境へのデプロイ用に、2つ目のパイプラインジョブを作成します。

1.2 パイプラインスクリプトの設定

以下のスクリプトをコピーしてパイプラインスクリプトとして貼り付けます。Build、DEV、QAで使用したスクリプトに似ています - PROD スクリプトには、"Download attributes for API" json ファイルから取得しなければならない2つの変数値があります。このファイルは、HCL Accelerate バリューストリームのツールアイコンからダウンロードできます。スクリプトをコピー＆ペーストし、正しい変数値を提供したら、Jenkins で「適用」と「保存」をクリックします。

parameters([
string(name: 'buildNumber', description: 'The version of the application to deploy.')
])
node {
//Get value for VSM_ENV_ID_PROD from HCL Accelerate VSM "Download attributes from API" json file.
def VSM_ENV_ID_PROD="0e9ea7c7-ed1d-43f2-9ebf-a5ab5161d61e"
//VSM_APP_NAME must match your HCL Accelerate pipeline application name
def VSM_APP_NAME="JKE App1"
currentBuild.displayName = "${buildNumber}"
stage ("Deploy to PROD") {
step([$class: 'UploadDeployment',
//"versionExtId" can be used in place of "id" and "versionName"
id: "${currentBuild.displayName}",
versionName: "${currentBuild.displayName}",
name: "${currentBuild.displayName}",
description: 'UploadBuild Example',
tenantId: "5ade13625558f2c6688d15ce",
initiator: "admin",
//Must specify one of "appId", "appExtId", or "appName"
appName: "${VSM_APP_NAME}",
environmentName: 'PROD',
environmentId: "${VSM_ENV_ID_PROD}",
result: "${currentBuild.currentResult}".toLowerCase(),
startTime: "${currentBuild.startTimeInMillis}",
endTime: "${System.currentTimeMillis()}",
type: "Jenkins",
debug: false,
fatal: false,
])
}
}

1.3 ジョブをパラメータ化する

パイプラインジョブを「buildNumber」という文字列パラメータでパラメータ化します。Apply をクリックして Save をクリックします。

2. HCL Accelerate パイプラインのセットアップ

PROD のデプロイメントは、DEV や QA のデプロイメントを設定するのとは少し違った方法で設定します。このチュートリアルでは、パイプラインにバージョンを提供する入力ジョブ(以前のビルドまたはディプロイメント)を設定します。パイプラインには、Jenkin ジョブにビルド番号を渡すパラメータ化された PROD ディプロイメントも含まれます。パイプラインに利用可能な入力バージョンを確認し、このバージョンをPROD環境にデプロイすることができるようになります。

2.1 入力ジョブを構成する

2.1.1 パイプラインから、関心のあるアプリケーション（この例では「JKE App1」）の「Input」の下の「+」をクリックします。

2.1.2 "Create Version "フォームで "Automatically "を選択し、ビルドを生成するJenkinsジョブを選択します。このチュートリアルでは、以前に作成した Build, DEV, QA Jenkins ジョブを使用します。

2.2 PRODの配置を設定する

PRODにデプロイするJenkinsジョブをPROD用のHCL Accelerateパイプライン環境に割り当てる（マップする）必要があります。また、ビルド番号にパイプラインパラメータを使用するように、このジョブを設定する必要があります。

2.2.1 パイプラインから、対象のアプリケーション（この例では「JKE App1」）の「PROD」の下の「+」をクリックします。

2.2.2 PRODにデプロイするために作成したジョブを選択し、「保存」をクリックします。

2.2.3 ビルドをデプロイメントにリンクさせるために、Jenkins ジョブのパラメータとして buildNumber を渡します。パラメータを使用してジョブを構成したので、この時点でパラメータを提供するように求められます。HCL Accelerateは、流動的なパイプラインをサポートするために、様々なバージョン/インベントリーのパラメータを用意しています。この場合、${version.buildNumber} をフォームに入力します。

これで、「入力」と「PROD」の両方の列の下に「まだ実行していない」と表示されるはずです。先に進み、HCL Accelerate に新しいビルド情報を提供するための最初の Jenkins ジョブ (入力ジョブ) を実行します。入力ジョブを実行すると、バージョン情報が表示されるはずです。

• Jenkins ジョブを実行する前に

• Jenkins ジョブを実行した後

3. ファイナルステージから PROD への変更

3.1 PROD へのパイプライン展開

3.1.1 HCL Accelerate パイプラインから、PROD の「Play」ボタンをクリックします。

3.1.2 最新版を選択して「デプロイ」をクリックします。これで、先ほど作成したパラメータ化されたJenkinsジョブが起動します。

3.1.3 ジョブが終了すると、パイプラインはバージョン番号とともに「Deployment succeeded」と表示されます。

価値の流れに戻る

バリューストリームに戻ると、ドットが最終段階であるPRODに向かって移動するのを見ることができます。

結論

これで、Jira、GitHub、Jenkinsのチュートリアルシリーズを終了します。私たちは、バックログから本番までのバリューストリームの旅全体をナビゲートし、途中で4つの別々のツールを使用しました：3つの外部ツール（Jira、GitHub、Jenkins）、そしてデプロイメントツールとしてのHCL Accelerate自体です。私たちは、ステージクエリ、統合、リンクルールを持つvsm.jsonファイル、パイプラインとデプロイメントなど、HCL Accelerateの主要な概念について学びました。ここから戻って、バリュー・ストリームの実験を始めることができます。手始めに、vsm.jsonファイルのステージとクエリを見ることから始めるのが良いでしょう。そこから、独自のプロセスに合わせてバリューストリームを形成し始めることができます。

2020/9/16 - 読み終える時間: 2 分

https://blog.hcltechsw.com/accelerate/survey-says-heres-what-the-market-really-thinks-of-value-stream-management/

Survey says...here's what the market really thinks of Value Stream Management

市場はバリュー・ストリーム・マネジメントについてどのように考えているのか

2020年9月15日

著者: Elise Yahner / HCL

バリューストリーム管理は、DevOps のソートリーダー、トレードショー、出版物などで話題になっていますが、ソフトウェア開発の専門家は VSM についてどのように考えているのでしょうか？これは、SD Times と提携してバリュー・ストリーム・マネジメント市場調査を行った際に、私たちが知りたかったことです。

SD Times は何百人もの読者を対象に、「バリュー・ストリーム管理のメリットについての現在の理解度はどうですか？結果は、VSMの認知度と採用はゆっくりと着実に進んでいますが、VSMを使用している人はすでに恩恵を受けていることを示しています。

最近、SD Times の編集長である Dave Rubinstein 氏は、ポッドキャストの中で、HCL Software DevOps の製品管理責任者である Steve Boone とこの調査について語りました。Boone によると、バリューストリームマネジメントは、VSM のアーリーアダプターと VSM のことを聞いたことがない人との間で、「交差する」地点にあると考えているとのことです。データはこれと一致しています。調査回答者の 3 分の 1 は、バリュー・ストリーム・マネジメントについて聞いたことがないと答えていますが、39%は VSM を導入する予定があるか、すでに VSM を実践していると答えています。

では、どうやって業界をその溝を越えさせるのか？教育とトレーニングです。「このソリューションには明らかに価値があるので、そのキャズムを越えて、一般的に採用が増えるまで、そう長くはかからないと思います。業界としては、人々にベストプラクティスを教育し、VSM がもたらしたデータを使って何か意味のあることをする方法を教えることが鍵となります」と Boone は指摘しました。

そのデータは、しばしばバラバラな DevOps ツールに隠されていますが、VSM の成功のハイライトとなっています。「ソフトウェア開発には、サイロ化されている部分がまだあり、組織の他の部分の人間が必ずしも見たり、洞察を得たり、行動に移すことができません。調査回答者の大多数が、「ソフトウェアデリバリパイプライン全体で進行中の作業の可視性が向上したこと」が、VSM の最も価値ある側面であると答えていることは、驚くに値しません」と Rubinstein 氏は述べています。

バリュー・ストリーム・マネジメントのあらゆる利点にもかかわらず、組織的、教育的な課題が VSM への参入を阻んでいます。調査回答者が挙げた課題のトップは経験の不足であり、資金調達や経営陣の協力が挙げられています。

しかし、Boone は「現在のプロセスについて、長く正直に振り返る必要があります」と述べ、VSM を始めるための最良の第一歩は、チームとの会話だとしています。「アイデアはどのようにしてバックログに入るのでしょうか？それが最終的にバックログから設計や計画の段階に移るのはいつですか？どのようにしてスプリントに入るのでしょうか？データはツールに隠されていますが、お互いの作業関係も理解しなければなりません」。

9月24日（木）午後3時（東部標準時）に開催されるパネルウェビナーでは、SD TimesのVSM調査結果について詳しくご紹介します。ウェビナーでは、SD Times の Dave Rubinstein 氏が、HCL Software DevOpsのエキスパートである Steve Boone、Chris Nowak、Bryant Schuck とバリューストリームマネジメント市場について議論します。登録はこちらをクリックしてください。