Cisco Service Portal インテグレーション ガイド リリース 9.3.2

偏向のない言語

この製品のマニュアルセットは、偏向のない言語を使用するように配慮されています。このマニュアルセットでの偏向のない言語とは、年齢、障害、性別、人種的アイデンティティ、民族的アイデンティティ、性的指向、社会経済的地位、およびインターセクショナリティに基づく差別を意味しない言語として定義されています。製品ソフトウェアのユーザーインターフェイスにハードコードされている言語、RFP のドキュメントに基づいて使用されている言語、または参照されているサードパーティ製品で使用されている言語によりドキュメントに例外が存在する場合があります。シスコのインクルーシブランゲージに対する取り組みの詳細は、こちらをご覧ください。

翻訳について

このドキュメントは、米国シスコ発行ドキュメントの参考和訳です。リンク情報につきましては、日本語版掲載時点で、英語版にアップデートがあり、リンク先のページが移動/変更されている場合がありますことをご了承ください。あくまでも参考和訳となりますので、正式な内容については米国サイトのドキュメントを参照ください。

マニュアルのコンテンツ
このマニュアル内で検索
ご利用いただける言語
Download Options

Book Title

Cisco Service Portal インテグレーション ガイド リリース 9.3.2

Chapter Title

Remedy サービス アダプタ

検索結果

Updated:
2017年6月19日

章のタイトル： Remedy サービス アダプタ

Remedy サービス アダプタ

• 「概要」

• 「前提条件」

• 「BMC Remedy の設定手順（例）」

• 「アダプタの入手」

• 「アダプタのインストール」

• 「アダプタの表示」

• 「エージェントの設定」

• 「変換の設定」

• 「Remedy アダプタが処理する要求に対応するサービスの設計」

• 「テスト シナリオ」

• 「ログ メッセージ」

概要

Cisco Service Adapter for BMC® Remedy® IT Service Management は、2 つの製品間の双方向統合です。Service Portal の My Services モジュール内で、サービス要求とインシデント/変更管理の両方に対応する単一のカスタマー ポータルを提供できます。リリース 9.3 よりも前のリリースでは、Service Portal の標準アダプタとしてライセンス提供されていました。現在は、カスタム アダプタとして Advanced Services から入手できます。

Service Adapter for BMC Remedy IT Service Management を使用では、次のことができます。

• カスタマーが My Services で要求を作成した後、Remedy システムのタスク レベルで 1 つまたは複数のチケットを作成できます。サービス要求プロセス内の 1 つまたは複数のタスクを、Remedy システムに統合できます。要件の履行プロセスの一部として、Remedy アダプタで個別のタスク レベルでチケットを作成し、Remedy システムに送信します。

• Remedy チケットおよび他の Remedy タスクのステータス更新情報を受信できます。AR System でチケットを作成すると、対応するワークフローが実行されます。ワークフローが正常に完了すると、AR System が Service Portal にステータス更新情報を送信します。または、Service Portal が AR System にステータス更新情報をポーリングすることもできます。

Service Link Adapter for BMC Remedy は、完全に非侵襲的です。AR System にコンポーネントをインストールする必要はありません。インターフェイス フォーム用として、AR System システムに単純な Remedy インターフェイス フォームを作成し、Web サービスとの中間層設定を有効にする必要があります。

Web サービス用の AR System 中間層が設定されると、Service Portal および Service Link が単純な AR System クライアント接続を使用して、Web サービスから AR System と通信します。AR System 中間層の Web サービスにアクセスするには、適切な AR System のライセンスが必要です。Web サービスからインターフェイス フォームに送信されたメッセージによって、実際の Remedy フォームでチケットが作成されるように、Remedy システムにワークフローを作成する必要があります。

Service Link データベースが AR System RDBMS にアクセスするため、JDBC 接続が必要です。AR System から Service Portal に情報を読み取るために使用するインターフェイス フォームのデータベース ビューに対応するインターフェイスに対して、適切な読み取り許可が必要です。

次の図に、Service Portal と AR System のシステム レベルの統合を示します。

 

統合のシナリオ

シナリオ 1：Service Portal で要求を作成し、AR System に送信して履行

ステップ 1 ユーザが Service Portal で要求を送信します。

ステップ 2 Service Portal がワークフローを処理し、要求の属性に基づき、目的の外部アプリケーションが AR System であることを識別します。

• Service Portal がメッセージをエージェント固有のキューに転送し、それを Service Link がピックアップして適切なアダプタに転送します。この場合は、SOAP Web サービス機能を備えた Remedy アダプタが組み込まれています。

ステップ 3 Service Link がメッセージを Remedy アダプタに転送します。Remedy アダプタが送信ドキュメントを取得し、送信ドキュメントに XSL 変換（XSLT）を適用して、SOAP 対応ドキュメントを作成します。次に、このアダプタがエージェント定義に含まれる接続情報を使用して、Remedy Tools を使用して Remedy AR System からエクスポートされた WSDL ドキュメントの記述に従い、Web サービスに対して適切な通信呼び出しを行います。

• Web サービスの呼び出しは、単一の同期呼び出しです。Web サービスを呼び出せなかった場合、Integration Server（Service Link）にエラーが返されます。

• Integration Server は、事前設定された再試行回数だけ、Web サービスの呼び出しを実行します。すべての再試行回数を実行し終わると、タスクは「Troubleshooting」状態になります。

• 「Troubleshooting」状態になったタスクは、Service Link で提供される手動処理（「Send Manual Message」）を使用して、再送信できます。

ステップ 4 Web サービスのサーバ側は、Remedy アダプタからの SOAP メッセージによって実行されるクライアント側呼び出しで呼び出されます。この Web サービスのサーバ側は、Remedy AR System 内にあります。

ステップ 5 Remedy AR System は、要求を処理し、SOAP Fault または SOAP Success を返します。

ステップ 6 Remedy アダプタは、「ProcessResponse」が true に設定されているため、呼び出された Web サービスへの応答を待ちます。

• 応答タイムアウトが経過すると、Integration Server にエラーが返されます。この場合、再試行回数が残っていれば、呼び出しが再試行されます。応答タイムアウトが経過していない場合、Business Engine 応答メッセージを作成する別の設定済み XSL 変換を通じて、返却メッセージが渡されます。メッセージによって、タスク関連の情報が更新されます。

ステップ 7 応答に SOAP Success が含まれている場合は、少なくとも、AR System から返されたチケット ID が含まれています。このチケット ID は、タスクに関連するサービス データの対応するフィールドの更新に使用されます。応答メッセージに SOAP Error が含まれている場合、AR System から返されたエラー情報でタスクの Comment セクションが更新されます。

 

シナリオ 2：AR System からステータス更新を受信

ステップ 1 AR System ユーザが、開いているチケットのステータスを変更したため、ステータスの変更を Service Portal に転送する必要があります。

ステップ 2 AR System のワークフローによって、Service Portal に関連する変更されたデータは、インターフェイス フォームの対応するデータベース テーブルに更新されます。Remedy システムのフォーム設定の一部として、データベース ビューが作成されます。

ステップ 3 Remedy Inbound Poller が AR データベースの対応するビューを定期的にポーリングし、処理して Service Portal に渡す必要がある新しいレコードがないか調べます。最後のポーリング日付と、データベース ビューの各レコードの修正日付を比較することで、新しく更新されたレコードが取得されます。データベース ビューには、作成されたチケットごとの行があります。

ステップ 4 変更されたデータベース レコードごとに、データベース ビューから情報が読み取られ、Business Engine メッセージに処理されます。Business Engine はメッセージを受信し、タスク情報を適切に更新します。

 

前提条件

Service Portal の要件

• Service Link モジュールがインストールされていること

• JDBC が BMC AR System データベースにアクセスできること

BMC の要件

• Remedy AR System が 5.X 以降であること

• Web サービスに対応した Remedy 中間層が有効になっていること

• サポートされる Remedy データベース プラットフォーム：Oracle 10g 以降、SQL Server 2005 以降

BMC Remedy の設定手順（例）

BMC Remedy を設定するには、次の手順に従います。

ステップ 1 Remedy データベースに対応するテーブルを作成する、使いやすいオプションを使用して、インターフェイス フォームを作成します。必要な場合、カスタム フィールドを追加します。

ステップ 2 このインターフェイス フォーム用の Web サービスを作成します。

ステップ 3 入力フィールドと出力フィールドの両方に対して、インターフェイス フォーム フィールドと Web サービス フィールドの間のマッピングを設定します。

ステップ 4 Web サービスの WSDL を生成します。

ステップ 5 インターフェイス フォームから Remedy Ticketing フォーム（変更管理フォームまたはインシデント管理フォーム）にデータを送信するワークフローを作成します。必要な場合、ワークフローで Remedy Ticketing フォームに事前入力（など）を行うフィルタを使用します。

ステップ 6 Web サービスの発信応答の定義に従って、データを Remedy Ticketing System からインターフェイス フォームに渡すワークフローを作成します。通常は、ステータス、優先度、またはビジネス要件に基づいたその他の更新情報です。ここでもフィルタを使用できます。

ステップ 7 Service Portal からメッセージを送信する前に、インターフェイス フォームから要求を作成して、Remedy ワークフローをテストし、システムが機能することを確認します。

ステップ 8 中間層サーブレット エンジンのライセンスが、複数のセッションをサポートしていることを確認します。

 

アダプタの入手

リリース 9.3 よりも前のリリースでは、Service Adapter for BMC Remedy はパッケージ化されたアダプタとして入手できました。リリース 9.3 以降、Remedy Service Adapter は、Cisco Advanced Services からのみ入手できるようになりました。

アダプタのインストール

カスタム アダプタのインストール方法については、『 Cisco Service Portal Configuration Guide 』を参照してください。

アダプタの表示

Service Adapter for BMC Remedy のインストール後、正常にインストールされたことを確認するには、次の Service Link ページを確認します。

インストールされているアダプタを表示するには、Service Portal を起動して [Service Link] を選択し、[Manage Integrations] > [Adapters] を選択して [Remedy Adapter] を選択します。次の図に示すように、アダプタのホーム ページが表示されます。

 

エージェントの設定

すべての Service Link 統合と同様、エージェントはアダプタを設定し、サービス定義とそのデータを、変換および統合するサードパーティ システムに関連付ける重要なコンポーネントです。

Remedy Agent には、Remedy システムのチケット作成要件を満たして機能するために必要な、必須プロパティがあります。次の表に、Remedy アダプタに必要なプロパティのセットとデフォルト値を示します。これらのプロパティの使用に関する詳細については、「Service Link」を参照してください。

名前
説明
デフォルト値

ContentType

発信 SOAP メッセージのコンテンツ タイプ

text/xml

RoutingURL

メッセージのルーティング先となる SOAP URL

Remedy WSDL から使用可能

AcceptUntrustedURL

対象の URL にセキュリティ証明書が必要かどうか

false

TimeOut

18000

ProcessResponse

Service Link が Web サービスから SOAP 応答を受け入れるかどうかを示す

true

Username

Web サービスを実行している Web サーバで SOAP メッセージを認証するための Integrated Windows Authentication（IWA）ユーザ名

IWA を適用する場合のみ

Password

IWA ユーザのパスワード

Domain

ユーザの IWA ドメイン

Realm

NTLM レルム

IWA を適用し、必要な場合

SOAPAction

WSDL で定義され、入力マップ タイプが CreateInputMap の SoapAction ヘッダー

JDBCUrl

Remedy データベースに接続して更新されたデータを読み取るための JDBC URL

jdbc:newscale:sqlserver://localhost:1433;DatabaseName=ARSystem など

JDBCDriverClass

データベースに接続するためのドライバ クラス

com.newscale.jdbc.UnifiedDriver

DBUserName

データベース ユーザ名

DBPassword

データベース パスワード

FormName

インターフェイス フォーム名または対応する DB ビュー名

FieldName_ModifiedDate

Remedy チケットの修正日が格納されているビューの列名

FieldName_CaseID

Remedy チケット ID が格納されているビューの列名

FieldName_Status

ステータス データが格納されているビューの列名

必須プロパティ以外に、サービス フォームから収集し、Remedy に送信して Remedy チケットに表示するエージェント パラメータを追加する必要があります。これらはカスタマー固有の値であり、ビジネス プロセスおよび要件にとって重要です。

次の図は、必須の値を含む設定済みの Remedy Agent の例を示しています。

発信プロパティ

 

着信プロパティ

 

Service Designer Integration Wizard は、Web サービス ベースのエージェントに関して、エージェント定義の作成の一部を自動化します。さらに、Cisco Advanced Services には、カスタマーが Remedy Agent 定義を作成する際に役立つツールがあります。ツールの入手方法については、シスコにお問い合わせください。

変換の設定

Service Link の発信および着信変換では、未加工の Service Portal データを Remedy WSDL が消費できるデータに変換するための XSLT、および Remedy から Cisco メッセージへの応答を変換する XSLT が定義されます。変換を作成するには、エージェントを設定し、2 つのシステム間で渡されるプロパティを確認した後、次の手順が必要です。

ステップ 1 任意のエディタで XLST を作成します。

ステップ 2 Service Link で [Manage Integrations] > [Transformations] を選択し、変換を作成します。

ステップ 3 変換を追加し、方向を「Outbound」に設定します。[Request] サブタブで、nsXML を Remedy SOAP 要求に変換する XLST を入力します。

ステップ 4 変換をもう 1 つ追加し、方向を「Inbound」に設定します。[Request] サブタブで、Remedy SOAP 応答を nsXML に変換する XLST を入力します。

次の項では、Service Portal データを Remedy チケット作成の基本的な必須フィールドに変換する XSLT の例について説明します。

 

着信変換の詳細

着信変換の例を次に示します。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
<xsl:template match="/">
<xsl:apply-templates select="inbound-results" />
<xsl:apply-templates select="soapenv:Envelope" />
</xsl:template>
<xsl:template match="inbound-results">
<message>
<xsl:attribute name="channel-id">
<xsl:value-of select="row/column[@name='sl_channelid']" />
</xsl:attribute>
<send-parameters>
<xsl:if test="row/column[@name='request_id']!='' and row/column[@name='request_id']!='null' ">
<agent-parameter>
<name>Request_ID</name>
<value><xsl:value-of select="row/column[@name='request_id']" /></value>
</agent-parameter>
</xsl:if>
<xsl:if test="row/column[@name='short_description']!='' and row/column[@name='short_description']!='null' ">
<agent-parameter>
<name>Short_Description</name>
<value><xsl:value-of select="row/column[@name='short_description']" /></value>
</agent-parameter>
</xsl:if>
</send-parameters>
<xsl:if test="row/column[@name='status']='4' or row/column[@name='status']='3'">
<take-action action="done" />
</xsl:if>
</message>
</xsl:template>
<xsl:template match="soapenv:Envelope">
<message>
<xsl:attribute name="channel-id">
<xsl:value-of select="//*[local-name()='SL_CHANNELID']" />
</xsl:attribute>
<send-parameters>
<xsl:if test="//*[local-name()='Request_ID']!=''">
<agent-parameter>
<name>Request_ID</name>
<value><xsl:value-of select="//*[local-name()='Request_ID']" /></value>
</agent-parameter>
</xsl:if>
</send-parameters>
</message>
</xsl:template>
</xsl:stylesheet>
 

発信変換の詳細

発信要求変換の例を次に示します。

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template name="main" match="/message/task-started">
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Header soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<AuthenticationInfo>
<userName>Demo</userName>
<password></password>
</AuthenticationInfo>
</soap:Header>
<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<OpCreate>
<Assigned_To><xsl:value-of select="/message/task-started/agent-parameter[name='Assigned_To']/value" /></Assigned_To>
<Short_Description><xsl:value-of select="/message/task-started/agent-parameter[name='Short_Description']/value" /></Short_Description>
<Status><xsl:value-of select="/message/task-started/agent-parameter[name='Status']/value" /></Status>
<Submitter><xsl:value-of select="/message/task-started/agent-parameter[name='Submitter']/value" /></Submitter>
</OpCreate>
</soap:Body>
</soap:Envelope>
</xsl:template>
<xsl:template name="taskcancelled" match="/message/task-canceled">
</xsl:template>
<xsl:template name="date_format">
<xsl:param name="text"/>
<!-- Break up the string into components -->
<xsl:variable name="date" select="substring-before($text,' ')"/>
<xsl:variable name="time" select="substring-after($text,' ')"/>
<xsl:variable name="hour" select="substring-before($time,':')"/>
<xsl:variable name="minute" select="substring-after($time,':')"/>
<!-- Reassemble the components applying rules -->
<xsl:value-of select="$date"/>
<!-- Add a T between date and time-->
<xsl:text>T</xsl:text>
<xsl:if test="not(string-length($hour)=2)">
<!-- Add leading 0 to hour if needed -->
<xsl:text>0</xsl:text>
</xsl:if>
<xsl:value-of select="$hour"/>
<xsl:text>:</xsl:text>
<xsl:value-of select="$minute"/>
<!-- Add seconds -->
<xsl:text>:00</xsl:text>
</xsl:template>
</xsl:stylesheet>
 

Service Designer Integration ウィザードは、カスタマーが Remedy 変換を作成するときに役立ちます。

発信および着信日付形式変換

発信メッセージと着信メッセージの両方で、発信および着信変換の日付形式は、国際日付/UTC に設定する必要があります。さらに、「Remedy インターフェイス フォーム データベース ビューの日付の変換」で説明するように、日付形式はデータベース ビューの秒から変換する必要があります。

次の表に、Remedy システムと Service Portal システムで必要な国際日付形式を示します。

システム
国際日付形式

Remedy

YYYY-MM-DDThh:mm:ssZ

Remedy に送信する日付は、すべてこの形式にする必要があります。末尾に追加された「Z」によって、UTC 日付であることが Remedy に通知されます。

Service Portal

YYYY-MM-DDThh:mm:ss

Service Link から Service Portal に送信される日付は、この国際日付形式にする必要があります。Service Portal は日付が UTC であると見なすため、末尾の「Z」は不要です。

変換 XSL テンプレート

発信変換

変換には、日付値を国際日付形式に変換するテンプレートが、あらかじめ用意されていない場合があります。次に示すように、変換の中で新しい日付値に「Z」を追加します。

<xsl:template name="intl_date_format">
<xsl:param name="remedy_date"/>
<!-- Break up the string into components -->
<xsl:variable name="date" select="substring-before($remedy_date,' ')"/>
<xsl:variable name="time" select="substring-after($remedy_date,' ')"/>
<xsl:variable name="hour" select="substring-before($time,':')"/>
<xsl:variable name="minute" select="substring-after($time,':')"/>
<!-- Reassemble the components applying rules -->
<xsl:value-of select="$date"/>
<!-- Add a T between date and time-->
<xsl:text>T</xsl:text>
<xsl:if test="not(string-length($hour)=2)">
<!-- Add leading 0 to hour if needed -->
<xsl:text>0</xsl:text>
</xsl:if>
<xsl:value-of select="$hour"/>
<xsl:text>:</xsl:text>
<xsl:value-of select="$minute"/>
<!-- Add seconds -->
<xsl:text>:00Z</xsl:text>
</xsl:template>
 

このテンプレートは、次のように使用します。

<xsl:call-template name="date_format"><xsl:with-param name=" remedy_date" select="/message/task-started/agent-parameter[name='Start_Date']/value" />
 

着信変換

変換には、日付値を国際日付形式に変換するテンプレートが、あらかじめ用意されていない場合があります。テンプレートは、Remedy 着信メッセージからの日付値を変換します。

<xsl:template name="intl_date_format">
<xsl:param name="remedy_date"/>
<xsl:value-of select="translate(substring-before($remedy_date, '.'),' ','T')" /></xsl:template>
 

このテンプレートは、次のように使用します。

<xsl:call-template name="intl_date_format"><xsl:with-param name="remedy_date" select="row/column[@name='end_date']" /></xsl:call-template>
 

Remedy インターフェイス フォーム データベース ビューの日付の変換

Service Link Remedy Agent が接続する Remedy データベースの Remedy DB ビューをカスタマイズする必要があります。DB ビューで日付値を保持する列は、日付値ではなく、秒数で格納されます。次の表で説明するように、ビューの SQL で、これを日付値に変換する必要があります。

RDBMS

SQL 文

Microsoft SQL Server

DATEADD(s, DBCOLUMN, '1970-01-01')

Oracle

(TO_DATE('01-JAN-1970') + DBCOLUMN / 86400)

Remedy アダプタが処理する要求に対応するサービスの設計

これで、すべての Service Link コンポーネントが作成され、Service Designer でエージェントを使用するサービスを作成できるようになりました。この手順は、Service Designer Integration ウィザードを使用して自動化できます。Web サービス ベースの Service Link エージェントの作成に関する詳細については、「Service Link」を参照してください。

ステップ 1 Service Designer で、Remedy に対して送受信する情報の収集に使用するディクショナリを作成します。

ステップ 2 Service Designer で、前のステップで作成した Remedy ディクショナリを含む Active Form Component（AFC）を作成します。

ステップ 3 Service Designer で、Remedy アダプタ アクティビティに使用するサービスを作成します。

ステップ 4 作成したサービスを選択し、[Forms] タブをクリックして、Active Form Component をサービスに追加します。

ステップ 5 [Plan] タブをクリックして、Remedy ワークフローを編成する外部タスクを作成します。

ステップ 6 必要に応じて、タスク エージェント マッピング ポップアップを使用して、Service Definition でエージェント値のマッピングを変更します。

ステップ 7 サービスを保存します。

 

テスト シナリオ

これで、すべての Remedy アダプタ コンポーネントが作成され、Service Definition にバインドされて、統合をテストする準備ができました。次に、統合が機能することを確認する簡単な手順を示します。

ステップ 1 Remedy Agent に関連付けられているサービスの Service Portal で、要求を作成します。

ステップ 2 要求に対応する Service Link で、Execute Task メッセージの受信を確認します。これは、Service Portal から Remedy への発信 SOAP 要求です。発信エージェント パラメータ マッピングで定義されているフィールドが含まれています。

ステップ 3 Service Link で、Send Parameters HTTP 応答の受信を確認します。これは、Remedy Web サービスの SOAP 応答です。Remedy Agent の ProcessResponse フラグが「True」に設定されている場合にのみ、メッセージが Service Portal で処理されます。

ステップ 4 対応する要求を、Remedy フォームで確認します。Remedy チケットに、SOAP 要求に含まれている情報と一致する情報が含まれていることを確認します。

ステップ 5 Remedy フォームを変更します。フォーム フィールド値とチケット ステータスを変更します。

ステップ 6 Service Link で、Send Parameters メッセージの受信を確認します。対応する要求エントリに、着信エージェント パラメータ マッピングに基づいて更新されたフォーム データが含まれていることを確認します。

ステップ 7 Remedy のステータスが Resolved、Closed、または Rejected のときに、Service Link で、Take Action（または Composite）メッセージの受信を確認します。着信変換で生成された take-action 操作によって、外部タスクのステータスが Completed に設定されます。

 

ログ メッセージ

 

メッセージ
説明
推奨処置

INFO メッセージ

実行中のタスクに関する情報。

ログの情報に従います。

DEBUG メッセージ

デバッグを可能にする、実行中のタスクに関する情報。

特定のタスクの詳細について、デバッグ メッセージに従います。

メッセージ ルーティング例外

メッセージのルーティングのエラー。

ルーティング URL が正しいことを確認します。URL をブラウザで開くと、Remedy 画面が表示されることを確認します。

内部システム エラー

Remedy 中間層または Remedy システムのエラー。

中間層からのエラー メッセージを示す SOAP 応答メッセージを調べます。
 

このドキュメントは役に立ちましたか?

Feedbackフィードバック

シスコに問い合わせ