次の方法で共有

Microsoft BizTalk Accelerator for RosettaNet (BTARN) の既知の問題

  • [アーティクル]

このセクションには、Microsoft® BizTalk Accelerator for RosettaNet (BTARN) のエラーを回避するのに役立つ情報が含まれています。 既知の問題は次の分野に分かれています。

  • 0A1 エラー通知

  • ビジネス アクティビティ監視 (BAM)

  • インストールと構成

  • その他

0A1 エラー通知

BTARN で CIDX プロセス構成プロパティと 0A1 アグリーメント プロパティのクロスフィールド検証が実行されない

BTARN では、CIDX が 0A1 契約をサポートしていない場合でも、そのプロファイルを使用する契約の "0A1 契約" プロパティを "0A1" に設定した後、プロセス構成プロファイルの "Standard" プロパティを "CIDX" に設定することはできません。

ビジネス アクティビティの監視

ビジネス アクティビティ監視レポートで列データが重複して表示される

BAM アクティビティ Web レポートの [ActivityID] 列と [PIPInstanceID] 列に同じ内容が格納されます。 このデータは、PIP (Partner Interface Process) インスタンス ID を正確に反映しています。 ActivityID は、この値を使用して内部照合を行います。 このメッセージは無視してかまいません。

ビジネス アクティビティ監視 Web レポートに空のデータ列がある

ビジネス アクティビティ監視 (BAM) の Web レポートに、0A1 メッセージ プロセスのデータがまったく記載されません。 Web レポートの 0A1 メッセージの列が "Initiated 0A1" でハード コードされます。

インストールと構成

BizTalk Application Users グループと BizTalk Server Administrators グループのいずれかで、グループとユーザーが同じドメインに存在する必要がある

BTARN では、BizTalk アプリケーション ユーザー グループまたは BizTalk Server Administrators グループへのグループの追加がサポートされています。 ただし、BizTalk Application Users グループまたは BizTalk Server Administrators グループに所属する個々のユーザー アカウントとグループが同じドメインに属していることが必要です。

BizTalk Server を先に削除すると BTARN のアンインストールに失敗する

BTARN を削除する前にBizTalk Serverを削除すると、エラーなしで BTARN の削除プロセスが失敗します。 この問題を解決するには、BizTalk Serverを再インストールして再構成し、BTARN を削除します。

分散展開にドメイン コントローラが必要である

マルチサーバー環境に BTARN を展開するには、ドメイン コントローラーが必要です。たとえば、あるサーバーに BTARN をインストールし、別のサーバーで構成に使用するSQL Server データベースをインストールした場合などです。

カスタム PIP 構成がサポートされていない

BTARN の現在のリリースでは、カスタム要素またはその他の RosettaNet 以外の標準情報を使用した PIP の構成はサポートされていません。

BTARN でシングル サインオン サービスが自動的に開始される

BTARN は、BTARN で要求され、SSO サービスが実行されていない場合に、イベントで Single Sign-On (SSO) を自動的に開始します。

WebApps が既定の Web サイト用に構成されていない場合、構成プログラムによりエクスクルード パスの一覧から BTARN 仮想ディレクトリが削除されない

Web アプリケーション仮想フォルダーが既定の Web サイトではなく SharePoint Server に構成されている BTARN インストールを構成解除した場合は、構成を解除した後、SharePoint サーバーの全体管理サイトの [除外されたパス] リストから btarnapp と btarnhttpreceive 仮想ディレクトリを手動で削除する必要があります。 これは、Web アプリケーションの仮想フォルダーを SharePoint Server に構成するときに、btarnapp および btarnhttpreceive を [エクスクルード パス] 一覧に手動で追加する必要があるためです。 構成プログラムでは、これらのディレクトリを [エクスクルード パス] 一覧から自動的に削除できません。

その他

どちらの暗号アルゴリズムで暗号化されているメッセージでも受信する

BTARN 受信パイプラインは、メッセージの暗号化に使用されるプロトコルと、このフィールドのエンコード設定が一致しない場合でも、メッセージを受信および復号化します。 そのため、BTARN は RC2-40 または 3DES のいずれかで暗号化されたメッセージを受信します。

シングル アクション同期シナリオでシグナルが必要である

単一アクション同期シナリオでは、BTARN は常にシグナルを想定して生成します。 この動作は、シングル アクションの同期シナリオではシグナルの必要性が場合に応じて変化する RosettaNet の仕様とは異なります。 BTARN がレスポンダーの場合、イニシエーターからのメッセージに応答して常にシグナルが生成されます。 BTARN がイニシエーターの場合、常にレスポンダーからのシグナルが返されます。 BTARN は、シグナルを受信しない場合、プロセス構成設定の プロパティで Time To Perform 指定された間隔の後にタイムアウトし、0A1 メッセージを生成します。

受信メッセージで UTF-16 がサポートされる

BTARN は、UTF-16 の文字セットを持つメッセージを受信して処理します。 BTARN は、UTF-8 の文字セットを含むメッセージを送信します。

要求メッセージからマップされた応答メッセージから名前空間を削除する必要がある

ダブル アクションのシナリオのプライベート プロセスで BizTalk マッパーを使用すると、BizTalk マッパーは、要求メッセージからマップされた応答メッセージ インスタンスの一部の要素タグに名前空間を追加します。 この名前空間により、送信パイプラインで障害が発生します。 したがって、この名前空間は削除する必要があります。 そのためには、HeaderHelper サンプルを使用します。 詳細については、「 Double Action PIPAutomation Orchestration [RN3]」 および 「Step 4: Creating the HeaderHelper Project [RN3]」を参照してください。

URI 設定を変更すると IISRESET が必要になる

セットアップ プログラムの実行中に、受信と送信の .aspx ページが使用する URI 設定、および受信と送信のアダプタの URI 設定が行われます。 .aspx ページまたはアダプタがインストールされているコンピュータの名前を変更する場合は、この設定を変更する必要があります。 構成処理を再実行することでこれらの設定を変更できますが、そのためには、構成設定をすべてリセットする必要があります。 関連付けられているレジストリ キー (AsyncReceivePortURI、、およびSyncReceivePortURI) を変更することで、RNIFSenderURIURI 設定を単独で変更できます。 このレジストリ設定のいずれかを変更した後は、変更を有効にするため、IISRESET を実行する必要があります。 これは、BTARN が使用する設定をキャッシュするためです。 IISRESET の実行後は、BizTalk サービスも再開する必要があります。

BTARN が RNIF v1.1 列挙には制約を実行しない

RosettaNet 実装フレームワーク (RNIF) 仕様 v1.1 では、一部の RNIF スキーマ列挙に対する制限が指定されています。 BTARN はこれらの制限を適用せず、これらの制限に対して検証も行いません。 この制約は RNIF V2.01 には適用されません。

これは、以下の Service Header 要素に適用されます。

  • GlobalBusinessActionCode

  • GlobalPartnerClassificationCode

  • GlobalBusinessServiceCode

  • GlobalProcessCode

  • GlobalProcessIndicatorCode

  • VersionIdentifier

PerformanceControlRequest パラメーターが既定のプロセス構成設定をオーバーライドしない

受信メッセージには、サービス ヘッダーにパラメーターを含 PerformanceControlRequest めることができます。 これらのパラメーターには、BTARN 管理コンソールで行われたプロセス構成設定で設定されているように、Time to Acknowledge (Receipt) と Time to Perform の time delay パラメーターの値が含まれます。 BTARN は、受信メッセージのパラメーターに基づいて遅延時間を PerformanceControlRequest 動的に設定しません。 BTARN は常に、プロセス構成設定で設定された既定の PIP 値から遅延時間を受け取ります。 この処理は RNIF (RosettaNet Implementation Framework) Specification V1.1 に準拠しています。

ダブルアクション メッセージの PIP 名と PIP バージョンで大文字と小文字が区別される

応答メッセージの PIP 名と PIP バージョンの大文字と小文字が、元の二重アクション要求メッセージの対応する値とは異なる場合、イニシエーター BTARN は応答メッセージを無効として拒否し、応答側に例外を返します。

アクティブなプロセスが存在する間はアグリーメントを変更できない

契約プロパティの変更は、[ 適用 ] または [OK] を クリックして同意するとすぐに適用されます。 アグリーメントを変更すると、そのアグリーメントが関係している、既に実行中のプロセスまたは新しいプロセスでの新しいアクティビティで、変更されたアグリーメント プロパティが使用されます。 アグリーメントを変更した時点で実行中のプロセスがあった場合、以前のアグリーメント プロパティが既にメッセージに使用されていた可能性があります。 このプロセスの新しいメッセージでは、新しいアグリーメント設定が使用されるので、予測不可能な結果が生じることがあります。 アグリーメント設定の変更は、実行中のプロセスがないときに行うことをお勧めします。

プロセス構成プロファイルの変更後にスフィールド検証が実行されない

プロセス構成プロファイルを作成してから契約を作成すると、BTARN はクロスフィールド検証を実行して、契約とプロファイルのプロパティに互換性があることを確認します。 たとえば、"CIDX" に設定されている標準プロパティを持つプロファイルに対して、アグリーメントの 0A1 アグリーメント プロパティが "非 0A1" に設定されていることが確認されます。 ただし、契約を作成した後にプロセス構成プロファイルを変更した場合、BTARN はクロスフィールド検証を実行しません。 Standard プロパティを "RosettaNet" から "CIDX" に変更した場合、BTARN は、契約の 0A1 アグリーメント プロパティが "No 0A1" に設定されていることを確認しません。

全部のオーケストレーションを開始しないとエラーが発生する

BTARN セットアップ プログラムでは、9 つのオーケストレーションがインストールされます。 BTARN がメッセージを正常に処理するには、処理を開始する前に、これらの 9 つのオーケストレーションをすべてバインド、参加、開始する必要があります。 詳細については、BizTalk Server ヘルプの「BizTalk エクスプローラーでのオーケストレーション管理」または「オーケストレーションの管理」トピックを参照してください。

RNIFReceive.aspx でメッセージから MIME の下位境界が削除されない

RNIFReceive.aspx ページが、パートナーの RNIFSend.aspx ページからメッセージを受信すると、メッセージには MIME ヘッダー、および MIME の上下の境界値 (64 進数) が埋め込まれます。 RNIFSend.aspx は、ヘッダーと境界を RNIF 送信のメッセージに追加します。 RNIFReceive.aspx は、メッセージをパブリック プロセスに送信する前に、メッセージから MIME ヘッダーと境界を削除する必要があります。 RNIFReceive.aspx は MIME ヘッダーと上位境界は削除しますが、下位境界は削除しません。 下位境界が存在しても、パブリック プロセスにおけるメッセージの処理には影響ありません。

SQL Server データベースの大文字小文字の区別の設定がサポートされない

BTARNSQL Server データベースとデータベース オブジェクトの大文字と小文字を区別すると、BTARN 管理コンソールはデータベース リソースを見つけられないので、例外をスローします。 BTARNSQL Server データベースとデータベース オブジェクトでは、大文字と小文字を区別しない必要があります。

データベース管理スクリプトのすべてのクエリを UTC 時刻形式で記述しなければならない

BTARN SQL Server データベースでは UTC (世界時座標) 時刻が使用されるため、これらのデータベースのいずれかを維持するために作成するすべてのクエリを UTC 時刻で書き込む必要があります。 たとえば、メンテナンス スクリプトで コマンドを使用 GetDate() する場合は、 に変更する GetUTCDate()必要があります。

PublicResponder オーケストレーションが重複する要求アクション メッセージを拒否する

PublicResponderオーケストレーション (PublicResponderV11.odx) が重複した要求アクション メッセージを受信すると、イベント ログに警告が記録され、メッセージが拒否されます。 応答側オーケストレーションの完了後に重複メッセージを受け取ると、サブスクリプションがないため、BizTalk Server がメッセージを停止します。

パブリック プロセスが停止した場合に転送エラーが BAM に表示されない

パブリック プロセスのオーケストレーションがその最終メッセージを処理するときに送信エラーが発生すると、イベント ログと HAT にはエラーが表示されますが、BAM には表示されません。 オーケストレーションが停止しているため、BAM にこのエラー メッセージを表示できません。

pipeline.exe ツールを使用して BTARN 受信パイプラインをデバッグできない

受信パイプラインをデバッグする場合、パイプラインをホストするポートを作成する必要があります。 BizTalk Serverが提供する pipeline.exe ツールを使用してデバッグすることはできません。

オーケストレーション完了後に正常に処理されたメッセージを再送するとエラーが生成される

BTARN はオーケストレーションを使用してプロセス フローを表します。 再試行メッセージがいくつか再試行される場合、再試行メッセージの 1 つが BizTalk MessageBox に到着しないうちにオーケストレーションが正常に終了することがあります。 この動作が発生すると、BizTalk Serverは対応する "完了したが破棄されました" というエラー メッセージを生成します。 プロセスが終了したかどうかを判断するには、基幹業務 (LOB) アプリケーションを確認する必要があります。 正常に終了したことが LOB アプリケーションで確認できた場合は、"完了したが破棄された" ことを示すエラー メッセージを無視してかまいません。

tracking.xls からエクスポートされた XML ファイルに間違ったフィールドが含まれている

tracking.xls ファイルに新しい追跡ビューを定義してこのファイルから XML ファイルをエクスポートすると、一部のフィールド名が若干変更されます。 これを修正するには、カスタマイズした追跡 XML ファイル内のフィールドを、BTARN セットアップによってインストールされた標準の tracking.xml フィールドに対して確認します。

シグナルと応答用の RNIF 1.1 サービス ヘッダー スキーマの変更が必要になる

BTARN では、すべての RosettaNet ヘッダー スキーマがすぐに出荷されます。 以下で説明するように、一部の実装では、Signal Control ノードと Action Control ノードの使い方が他と異なります。

BTARN には、以下のように Signal Control 要素が付属しています。 場合によっては、Action Control 要素にも同様のことが言えます。

<!ELEMENT SignalControl (  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity,  
          inResponseTo)>

使用するソリューションにこのシーケンスが必要な場合は、何もする必要がありません。

また、実装によっては次のコードを使用してください。

<!ELEMENT SignalControl (  
          inResponseTo,  
          InstanceIdentifier,  
          PartnerRoute,  
          SignalIdentity)>

使用するソリューションにこのシーケンスが必要な場合は、サポート技術情報の記事 889523 を参照してください。 このソフトウェア更新プログラムによって、対応する XML スキーマが変更されます。 この更新プログラムは RNIF 1.1 プロセスのみに影響することに注意してください。

PipAutomationGetAction SQL ストアド プロシージャの更新が必要である

単一レコードをロックするには、PipAutomationGetAction SQL ストアド プロシージャを更新する必要があります。 次の行を削除します。

IF @@ERROR <> 0  
    UPDATE MessagesToLOB SET Delivered = -1 WHERE MessageID = @tempGUID

正しい PipAutomationGetAction ストアド プロシージャは、次のとおりです。

CREATE PROCEDURE PipAutomationGetAction  
AS  
 SET TRANSACTION ISOLATION LEVEL READ COMMITTED  
BEGIN TRANSACTION  
DECLARE @tempGUID nvarchar(36)  
SELECT TOP 1 @tempGUID = MessageID FROM MessagesToLOB WITH (READPAST,UPDLOCK,ROWLOCK)  
   WHERE Delivered = 0 AND MessageCategory = 10  
  ORDER BY TimeCreated  
  SELECT PIPInstanceID,DestinationPartyName,SourcePartyName,PIPCode,PIPVersion, ServiceContent FROM MessagesToLOB  
   WHERE MessageID = @tempGUID  
For xml auto  
UPDATE MessagesToLOB SET Delivered = 1 WHERE MessageID = @tempGUID  
 COMMIT TRANSACTION  
GO

エラーの説明を返すように aspx コードをカスタマイズできる

エラーの説明を記録したり送信したりする必要がある場合、aspx コードをカスタマイズして、応答メッセージに実際のテキストを含めることができます。 これを行うには、HttpResponse.Status (組み込みの asp 要求の応答オブジェクト) または HttpWebResponse.StatusDescription (HttpWebRequest オブジェクトの GetResponse メソッドへの .NET 呼び出しによって返されます) を使用します。 該当する応答オブジェクトの 1 つから戻り値を返すには、BTARN に付属する aspx コードで Response.StatusCode を設定する方法と同様に Response.Status 値を設定します。

エンコード方式を Base64 に設定している場合に否認不可テーブルから RNIF 1.1 のメッセージをプレーン テキストで読むことができない

これはエンコード方式が Base64 に設定されている場合にのみ発生します。 エンコード方式が quoted-printable または 8 ビットに設定されている場合は、否認不可テーブルからメッセージをクリア テキストで読むことができます。 メッセージを参照するには、メッセージ ファイルを拡張子 *.eml で保存してから、Outlook Express でそれを開くと、自動的にデコードされます。 または、以下のコードを使用すると、Base64 でエンコードされているメッセージを否認不可テーブルから読むことができます。

byte[] textBytes = Convert.FromBase64String(txtEncodedText.Text);  
string plainText = Encoding.UTF8.GetString(textBytes);  
txtOutput.Text = plainText;

参照

トラブルシューティングと既知の問題