SAP STMSトランスポート管理：設定、インポートキュー、障害対応の実務

SAPの開発・品質保証・本番システム間で移送依頼を安全に運用するには、変更の作成、リリース、ファイル転送、インポート、結果確認を一つの流れとして管理します。SAP GUIのトランザクションコード STMS は、この運用を管理する中心的な画面です。

この記事では、SAP Basis担当者がSTMSを使うときの初期確認、トランスポートドメイン設定、インポートキューの扱い、RCの調査、障害発生時の切り分けをまとめます。システム変更の承認手順や本番インポートの時間帯は、組織の変更管理プロセスに合わせて運用してください。

01STMSで管理する移送の全体像

SAPトランスポートは、通常、開発システムで変更を作成し、移送依頼をリリースした後、品質保証システムで検証し、承認後に本番システムへインポートします。STMSは、各システムの接続関係、移送ルート、インポートキュー、インポート履歴を確認するために使用します。

代表的な流れは次のとおりです。

1. 開発システムで設定またはリポジトリ変更を行う。
2. 変更を移送依頼に記録する。
3. 依頼内のタスクを完了し、依頼をリリースする。
4. リリース済みの依頼を移送ディレクトリへ転送する。
5. 品質保証システムのインポートキューで依頼を確認する。
6. インポートを実行し、インポートログとRCを確認する。
7. 検証結果と承認を確認して、本番システムへ同じ手順で移送する。

依頼番号だけで判断せず、依頼の説明、所有者、作成元、リリース日時、前提となる依頼を合わせて確認します。依頼の順序が機能の依存関係に対応している場合は、キュー内の順序を維持したままインポートします。

SAP Basisの日常運用全体とSTMSの位置付けを整理する場合は、SAP Basisシステム管理の実務ガイドも参照してください。

02トランスポートドメインを設定する

STMSを最初に開いたシステムでは、トランスポートドメインの設定を求められることがあります。一般的には、運用の基準となるシステムをドメインコントローラとして選び、ドメイン名とトランスポートディレクトリを確認して保存します。

設定前に、次の項目を決めておきます。

• ドメインコントローラとして使用するSAPシステム
• ドメインに参加させる各SAPシステムのSIDとホスト名
• トランスポートディレクトリの共有状態とアクセス権
• システム間で使用する接続方式と通信ポート
• インポートを実行する担当者と承認者

ドメインコントローラの設定後、他のシステムからSTMSを開いてドメイン参加を実行します。ドメインコントローラ側では参加要求を確認し、システム一覧と通信状態を確認します。システム名、SID、インスタンス番号、ホスト名に誤りがあると、後続の接続テストやファイル転送で問題が発生します。

設定変更後は、STMSのシステム概要、通信テスト、トランスポートツールのログを順に確認します。複数のSAPシステムが同じトランスポートディレクトリを参照する構成では、OSレベルの共有権限、所有者、グループ、マウント状態も確認対象です。

03移送ルートとインポートキューを確認する

STMSの移送ルート画面では、開発システムから品質保証システム、品質保証システムから本番システムへ向かう経路を確認します。ルートはシステムの役割と変更管理プロセスに合うように設計し、テスト用システムと本番システムを誤って直接接続しないようにします。

インポートキューでは、次の項目を確認します。

• 移送依頼の番号と説明
• 依頼の作成元システム
• 依頼のリリース状態
• キュー内の順序
• 前提依頼や関連依頼の有無
• インポート済み、保留中、エラーなどの状態

キューに依頼が表示されない場合は、まず開発システムで依頼がリリース済みか確認します。次に、移送ファイルがトランスポートディレクトリへ転送されているか、対象システムが正しいルートに接続されているかを確認します。ファイルが存在していても、OS権限や共有ディレクトリの状態によってSAPシステムから読み取れないことがあります。

トランザクションコードを目的別に確認したい場合は、SAPトランザクションコード一覧を参照してください。STMSを開く前に、対象システムと実行する操作を明確にすると誤操作を減らせます。

04トランスポート依頼をインポートする

本番システムへのインポートでは、対象システム、依頼番号、承認状態、実行時間帯、業務影響を確認してから操作します。インポートキューで対象依頼を選択し、インポート操作を開始した後は、処理が完了するまでログを確認します。

実行前には、次のチェックを行います。

1. 依頼が意図したシステムからリリースされている。
2. 依頼の説明と変更内容が作業記録と一致している。
3. 先行する依頼がすでにインポートされている。
4. 対象システムの空き時間とバックアップ状況を確認している。
5. インポート後の確認担当者と確認項目が決まっている。

インポート完了後は、RCだけでなく、警告の内容、戻り値の詳細、アプリケーション動作を確認します。RCが成功を示していても、設定値や権限、連携先の状態が期待どおりとは限りません。画面確認、ジョブ確認、連携テストなど、変更内容に応じた業務確認を続けます。

インポート後にエラーが出た場合は、同じ依頼を繰り返し実行する前に、ログの対象オブジェクト、エラーの発生段階、前提依頼、データベース変更の有無を確認します。再実行、依頼の修正、後続依頼の停止、別依頼による補正のどれを選ぶかは、変更の影響範囲を確認して決定します。

05インポートログとRCを分析する

インポート結果は、STMSのインポート履歴と詳細ログから確認します。ログでは、インポートの開始・終了時刻、実行ユーザー、対象依頼、処理されたオブジェクト、警告、エラーを確認します。

RCの値だけでなく、次の観点で分析します。

• 依頼全体の結果と個別オブジェクトの結果が一致しているか
• 警告が単なる情報か、後続処理に影響する内容か
• DDIC変更、プログラム変更、権限変更、設定変更のどこで発生したか
• 依頼の前提となるオブジェクトが対象システムに存在するか
• インポート後に生成処理やキャッシュ更新が必要か

移送依頼のインポート後に短いダンプ、ロック、ジョブ失敗などが発生した場合は、インポート時刻と障害発生時刻を照合します。システムログを調査する場合は、SAPシステムログSM21の確認方法を参照してください。

アプリケーション側のエラーだけでなく、ファイルシステム、ジョブ、RFC、データベース接続などの周辺要因も確認します。RFC接続が関係する移送やインポート後処理では、接続先、ユーザー、認証、接続テストの結果を確認します。RFC宛先の管理については、SAP RFC宛先SM59の設定と確認が役立ちます。

06STMSの代表的な障害を切り分ける

インポートキューに依頼がない場合

開発システムで依頼がリリース済みか、対象システムのキューを更新したか、移送ルートが正しいかを確認します。移送ディレクトリ内の依頼ファイルとデータファイルについて、作成日時、所有者、グループ、読み取り権限を確認します。

システム間の通信テストが失敗する場合

対象システムのホスト名解決、ネットワーク接続、SAPインスタンスの稼働状態、ゲートウェイ関連の設定を確認します。ホスト名やインスタンス番号の登録に誤りがある場合は、STMSのシステム設定と実際のシステム情報を照合します。

インポートがエラーで終了する場合

詳細ログから最初に発生したエラーを特定します。後続のエラーは先行エラーの影響を受けていることがあるため、最後に表示された行だけで判断しません。オブジェクトのロック、未処理の前提依頼、権限不足、構文エラー、データ不整合を順に確認します。

依頼の順序に問題がある場合

依頼間の依存関係を開発担当者に確認し、キュー内の順序を見直します。後続依頼だけを先にインポートすると、定義と利用側の不整合が発生することがあります。すでに一部をインポートした場合は、変更記録を残し、補正依頼や再インポートの影響を整理します。

07安全なトランスポート運用を定着させる

本番移送では、申請、承認、実行、検証、結果記録を分離すると、誤操作と追跡不能を減らせます。緊急変更を扱う場合も、依頼番号、承認者、実行時刻、結果、ロールバック方針を記録します。

運用手順には、少なくとも次の項目を含めます。

• 開発・品質保証・本番のシステム一覧
• 各システムの役割と接続先
• インポート可能な時間帯
• 事前バックアップと業務確認の条件
• インポートログの保存場所
• エラー発生時の連絡先とエスカレーション基準
• 依頼の再実行や取り消しを判断する責任者

定期的に、未処理の依頼、長期間キューに残る依頼、失敗したインポート、通信エラーを棚卸しします。不要な依頼を削除する前には、関連する変更記録と後続依頼への影響を確認します。STMSの設定変更やルート変更は、通常の移送とは別に記録し、変更後の通信テストまで完了させます。

08まとめ

STMSの安定運用では、ドメイン設定、移送ルート、インポートキュー、詳細ログ、業務確認を一続きの管理対象として扱います。依頼番号やRCだけで判断せず、依頼の順序、前提関係、対象オブジェクト、インポート後のシステム動作を確認することが重要です。

障害発生時は、キューに表示される前のファイル転送、システム間通信、インポート実行、アプリケーション確認のどの段階で問題が起きたかを切り分けます。この順序で確認すると、STMS画面だけでは見えないOS、RFC、ジョブ、システムログの問題も整理しやすくなります。