Amazon Web Services ブログ

Amazon API Gatewayを使用したSAP IDocとAmazon S3の統合

Amazon Web Services (AWS)上でSAPワークロードを稼働している私たちのお客様は、同様にAWS上のデータレイクソリューションを使用することでデータと分析の変換に投資されています。これらのお客様は、さまざまなサードパーティソリューションを使用してSAPアプリケーションからデータを抽出することがあります。ただし、パフォーマンス向上とコスト削減のために、AWSソリューションを使用するネイティブ統合も必要とされています。

これらのお客様がSAPアプリケーションからデータを抽出するために使用する一般的なパターンは、IDocインターフェース/電子データ交換です。SAP NetWeaver ABAPベースのシステムは、長い間IDocをサポートしています。IDocは非常に安定したフレームワークであり、SAPシステムと非SAPシステム間でのマスターデータとトランザクションデータの配信を支えます。

SAP IDocをAmazon Simple Storage Service (Amazon S3)と統合するためのアーキテクチャ上のアプローチは、ブログ記事「Integrating SAP’s IDOC Interface into Amazon API Gateway and AWS Lambda」のように、既にSAPコミュニティで公開されています。しかしながら、これらのアプローチでは、本稼働環境で使用する上で重要なセキュリティ面がカバーされていません。不正なユーザーの脅威から守るためにビジネスクリティカルなAPIを保護することは重要です。

このブログ記事では、AWS Lambda オーソライザーとAmazon Cognitoで認証レイヤーを提供し、Amazon API Gatewayを使用してSAP IDocをAmazon S3に格納する方法を紹介します。

AWS Lambda オーソライザーは、Lambda関数を使用してAPIへのアクセスを制御するAmazon API Gatewayの機能です。AWS Lambda オーソライザーの詳細については、「API Gateway Lambda オーソライザーの使用」を参照してください。Amazon Cognitoを使用することで、Web、モバイル、統合アプリにユーザーサインインおよびアクセス制御メカニズムを追加できます。Amazon Cognitoの詳細については、「Amazon Cognitoの開始方法」を参照してください。

ユースケース

最初に、このブログ記事で紹介するアーキテクチャの恩恵を受けるユースケースとビジネスプロセスのいくつかを見てみましょう。

マスターデータ統合: SAPアプリケーションが、品目マスターや得意先マスターなどのすべてのマスターデータの真の情報源であり、このマスターデータを非SAPアプリケーションや他のSoftware as a Service (SaaS)と統合しているとしましょう。SAPでApplication Link Enabling (ALE)を設定し、Amazon S3に格納するためのIDocとしてSAPからマスターデータを抽出することができます。一旦データがAmazon S3に到達したら、マスターデータを他のアプリケーションと統合するか、データレイクソリューションからデータを活用できます。ALEでサポートされているすべてのマスターデータオブジェクトの一覧については、配信可能なマスターデータオブジェクトを参照してください。

企業間取引 (B2B)統合: IDocは依然としてB2B統合シナリオで広く使用されています。ユースケースには、銀行との財務データの統合、サプライヤーとの在庫や品目マスターデータの統合が含まれます。IDocを通じてサポートされているビジネスプロセス統合の完全なリストについては、配信可能なマスタデータオブジェクトを参照してください。IDocデータをAmazon S3に持ってくることで、カスタム開発をほどんど行わなくても、既存の統合機能を活用することができます。

アーキテクチャ

次のアーキテクチャ図は、IDocをAmazon S3と統合するためのワークフローを示しています。これには基本認証が組み込まれています。

  1. SAP IDocは、HTTPSエンドポイントへのXMLペイロードとして記述できます。このアーキテクチャでは、SAP内でHTTPSベースのRemote Function Call (RFC)宛先に割り当てるIDocポートを作成します。難しい設定などは一切無しで、HTTPSベースのRFC宛先は、ユーザー名とパスワードによる基本認証をサポートしています。ここでは、HTTP宛先はAmazon API Gatewayのエンドポイントを指しています。
  2. Amazon API Gatewayで基本認証をサポートするには、WWW-Authenticate レスポンスヘッダーを使用してコード401を返すゲートウェイレスポンスを有効にします。次に、ユーザー名とパスワードを検証するために、Lambda オーソライザー機能を使用します。
  3. Lambda オーソライザーは、リクエストヘッダーからユーザー名とパスワードを、リクエストクエリパラメータからAmazon Cognito ユーザープールIDとクライアントIDを読み取ります。次に、Amazon Cognito ユーザープールに対する管理者としての認証を開始します。正しいユーザー名とパスワードが入力されると、Amazon Cognito プールはJSON Web Token (JWT)を発行します。有効なJWTを受け取ると、Lambda オーソライザーはAPIコールを続行することを許可します。
  4. 承認されると、Amazon API Gatewayは別のLambda関数を起動してIDocデータを処理します。
  5. Lambda関数はリクエストボディからIDocペイロード情報を読み取り、AWS SDKを使用してIDocデータをXMLファイルとしてS3 バケットに書き込みます。

データがAmazon S3で利用可能になったら、データ変換のためにAWS Glueなどの他のAWSソリューションを使用し、そのデータをAmazon RedshiftやAmazon DynamoDBなどにロードできます。

設定方法

前提条件

  • AWSアカウントおよびリージョン用にAWS Command Line Interface (AWS CLI)を設定します。詳細については、AW​​S CLIの設定を参照してください。
  • AWS CloudFormationを使用してリソースを作成するために、AWSアカウントの管理者権限を取得します。
  • 証明書のアップロード、RFC宛先とIDocポートとパートナープロファイルを作成するために、SAPアプリケーションの管理者権限を取得します。

AWSの設定

次に、以下の手順に従ってこの統合を実装します。必要なAWSリソースを簡単に作成できるように、AWS CloudFormationテンプレート、Lambda関数、展開用のスクリプトをGitHubリポジトリに公開しています。

このCloudFormationテンプレートによって作成されたリソースの利用にはコストがかかることに注意してください。作成されるリソースの完全なリストについては、このブログ記事の「CloudFormationリソース」セクションを参照してください。

ステップ 1:

ローカルマシンにaws-cloudformation-apigw-sap-idocs GitHubリポジトリをクローンします。

$ git clone https://github.com/aws-samples/aws-cloudformation-apigw-sap-idocs.git

ステップ 2:

ターミナル/コマンドウィンドウで、ダウンロードしたフォルダに移動します。

$ cd aws-cloudformation-apigw-sap-idocs

ステップ 3:

build.shファイルの実行アクセス権を変更し、build.shスクリプトを実行します。

$ chmod +x build.sh
$ ./build.sh

ステップ 4:

これでビルドフォルダが作成されます。新しく作成したビルドフォルダに移動します。

$ cd build

ステップ 5:

deploystack.shファイルを開き、必要に応じて変数の値を編集します。少なくとも次の変数の値は変更してください。

  • S3BucketForArtifacts – CloudFormationテンプレートが必要とするすべてのアーティファクトが保存される場所
  • USERNAME – Amazon Cognitoのユーザー名
  • EMAILID – Amazon Cognitoのユーザー名に紐づいている電子メールID

ステップ 6:

deploystack.shファイルの実行アクセス権を変更して、スクリプトを実行してください。AWS Command Line Interface (AWS CLI)が正しいAWSアカウントとリージョンに設定されていることを確認してください。詳細については、AW​​S CLIの設定を参照してください。

$ chmod +x deploystack.sh

$ ./deploystack.sh

このスクリプトは次のことを行います。

  • AWSアカウントにS3 バケットを作成 (deploystack.shファイルの変数S3BucketForArtifactsに指定した名称で)
  • 必要なファイルをすべてS3 バケットにアップロード
  • AWSアカウントでCloudFormationテンプレートを展開
  • すべてのリソースが作成されたら、Amazon Cognito ユーザーを作成 (deploystack.shファイルの変数USERNAMEに指定した値で)
  • パスワードを設定 (スクリプトを実行したときに指定した値で)

作成されるリソースについては、このブログ記事の「CloudFormationリソース」セクションを参照してください。

SAPの設定

ランドスケープ内の既存のSAPアプリケーションで以下のステップを実行するか、またはSAP Cloud Appliance Libraryを使用してSAP ABAP Developer Editionシステムを立ち上げることができます。Amazon VPCにスタンドアロンのSAP ABAP Developer Editionシステムをインストールしたい場合、GitHubリポジトリに導入作業を高速化するためのCloudFormationテンプレートを用意しています。

SAPでRFC接続を構成

ステップ 1:

SAPアプリケーションがAmazon API Gatewayのエンドポイントに接続すると、証明書が提示されます。SAPアプリケーションがこの証明書を信頼するには、トランザクションコードSTRUSTを使用してSAP証明書ストアに証明書をアップロードする必要があります。Amazon Trust ServicesからAmazonサーバーの証明書をダウンロードできます。そのWebページのルートCAの箇所で、すべてのルートCA (DER形式)をダウンロードし、トランザクションコードSTRUSTを使用してそれらをSSLクライアントのSSLクライアント (標準)ノードにアップロードします。このノードが存在しない場合は作成してください。SSLクライアントPSEの詳細については、標準SSLクライアントPSEの作成を参照してください。

trust manager

ステップ 2:

AWSマネジメントコンソールを開き、AWS CloudFormationに移動します。このブログ記事の前半の「AWSの設定」で展開したスタックを選択してください。次に、[ 出力 ]タブに移動し、IDOCAdapterHostキーとIDOCAdapterPrefixキーの値を書き留めます。次のステップでこれらの値が必要になります。

outputs

ステップ 3:

SAPアプリケーションで、トランザクションコードSM59を実行して、タイプG (外部サーバーへのHTTP接続)のRFC宛先を登録します。[ ターゲットホスト ]には、前のステップで書き留めたIDOCAdapterHostキーの値を入力します。同様に、[ パスプレフィックス ]にIDOCAdapterPrefixキーの値を入力します。また、[ サービス番号 ]には、[ 443 ]と入力します。すべての詳細を入力したら、[ Enter ]を押します。クエリパラメータは許可されていないという警告が表示されるかもしれません。もう一度 [ Enter ]を押すと、その警告を無視できます。

rfc destination

ステップ 4:

このままトランザクションコードSM59の画面で、[ ログオンとセキュリティ ]タブを選択して、[ 基本認証 ]を選択します。[ ユーザー ]欄には、このブログ記事の前半の「AWSの設定」で使用したUSERNAMEの値を入力します。[ パスワード ]欄には、「AWSの設定」で使用したPASSWORDの値を入力します。そして、[ セキュリティオプション ]の下部にある、[ SSL ]は[ アクティブ ]を、[ SSL証明書 ]は[ デフォルトSSLクライアント (標準) ]を選択します。

rfc ssl certificate

ステップ 5:

[ 接続テスト]を選択すると、Amazon API GatewayからHTTP応答200が返されます。エラーが発生した場合は、[ ターゲットホスト ]欄を再確認し (HTTPまたはHTTPSで始まってはいけません)、サービス番号が443であることを確認し、パスプレフィックスが正しいことを確認します (/で始まり、完全なクエリ文字列が含まれている必要があります)。正しいユーザー名とパスワードを入力したかどうかを確認してください。また、[ SSL ] が[ アクティブ ]で、[ SSL証明書の値 ]が [ デフォルトSSLクライアント (標準) ]であるかどうかを確認してください。

test connection

IDocポートとパートナープロファイルの構成

ステップ 1:

トランザクションコードWE21を実行し、このブログ記事の「SAPの設定」で作成したRFC宛先を使用してXML HTTPタイプのポートを作成します。[ コンテンツの種類 ]には、[ テキスト/ XML ]を選択します。

ports in idoc processing

ステップ 2:

トランザクションコードBD54を実行して、新しい論理システム (例えば、AWSAPIGWなど)を作成します。

ステップ 3:

トランザクションコードWE20を実行して、タイプLSの新規パートナプロファイルを作成します。

partner type ls

ステップ 4:

トランザクションコードWE20から、前のステップで作成したパートナプロファイル用の送信パラメータを作成します。テスト目的で、メッセージタイプとしてFLIGHTBOOKING_CREATEFROMDATを、受信ポートとしてこのブログ記事の「 SAPの設定」で作成したポート名 (例えば、AWSSAPIGWなど)を、基本IDocタイプとしてFLIGHTBOOKING_CREATEFROMDAT01を選択します。

outbound parameters

送信IDocでテスト

ステップ 1:

トランザクションコードWE19を実行します。[ Viaメッセージタイプ ]欄には、LIGHTBOOKING_CREATEFROMDATを入力し、[ 実行 ]を選択します。

test tool for idoc processing

ステップ 2:

制御レコード項目を編集するには、[ EDIDC ]欄をダブルクリックします。[ 受信者 ]と[ 送信者 ]の詳細を入力します。受信側のパートナー番号は、システムIDとクライアントによって異なります。この例では、システムIDはNPL、クライアントは001です。トランザクションコードBD54で論理システム名を確認してください。

test tool for idoc processing

ステップ 3:

E1SBO_CREとE1BPSBONEWノードをダブルクリックして、いくつかの値を入力します。ここは何を指定してもかまいません。フィールド値に対する検証はありません。完了したら、[ 標準送信処理 ]を選択します。これにより、IDocデータがAmazon API Gatewayのエンドポイントに送信されます。

outbound processing of idoc

ステップ 4:

前にCloudFormationによって作成されたS3 バケットにIDocデータが格納されているかどうかを検証します。

s3 bucket

Amazon CognitoとAWS Identity and Access Management (IAM)

このアーキテクチャではAmazon Cognitoを使用しています。これは、ユーザーストアに対してユーザーを認証し、短期間の認証情報を発行するための柔軟性を提供するためです。ただし、IAMユーザーのアクセスキーを使用したい場合は、RFC宛先のユーザー名にアクセスキーIDを、パスワードにシークレットアクセスキーを使用することができます。

Lambda関数apigw-sap-idoc-authorizerは、最初にAmazon Cognitoでユーザーを認証しようとします。失敗した場合は、アクセスキーとシークレットアクセスキーを使用して認証を試みます。これらのキーを持つユーザーが、IDocデータが格納されているS3 バケットへの「リスト」アクセス権を持っていることを確認してください。詳細については、Lambda関数apigw-sap-idoc-authorizerのインラインドキュメントを参照してください。また、Amazon Cognitoの代わりにそれらを使用することを選択した場合は、AWSアクセスキーを維持するためのベストプラクティスに従うようにしてください。

CloudFormationリソース

次のリソースが、このブログ記事の前半の「AWSの設定」で展開したCloudFormationテンプレートによって作成されます。

Amazon Cognito ユーザープール: SAPアプリケーションからユーザー名とパスワードの認証フローをサポートするために、CloudFormationテンプレートは、<Environment>_user_poolの名称 (例えば、sapidocs_user_poolなど)のAmazon Cognito ユーザープールを作成します。<Environment>はCloudFormationテンプレートの入力パラメータです。このユーザープールはユーザーストアとして機能するように設定され、電子メールIDが必須のユーザ属性として設定されています。パスワードポリシーも適用されます。

Amazon Cognito ユーザープールクライアント: アプリクライアントもAmazon Cognito ユーザープールに作成されます。このアプリクライアントは、サーバーベースの認証でサインイン API を有効にする (ADMIN_NO_SRP_AUTH)、およびアプリベースの認証でユーザー名とパスワードの (SRP を使用しない) フローを有効にする (USER_PASSWORD_AUTH)に設定されています。これら2つの設定により、Amazon API Gatewayを呼び出すときにSAPから提供された認証情報を使用して、Lambda オーソライザー機能がAmazon Cognito ユーザープールに対してユーザーを認証します。

Amazon S3 バケット: <Your AWS Account ID>-<S3BucketForIDOCパラメータの値>という名称のS3 バケット (例えば、123456789-sapidocsなど)が作成され、IDoc XMLファイルが格納されます。

Lambda オーソライザー機能: apigw-sap-idoc-authorizerという名称のNode.jsのLambda関数は、リクエストの中で提供されるユーザー名/パスワードを使用してAmazon Cognitoに対する管理者としての認証を実行することによって、SAPからAmazon API Gatewayへのリクエストを認証するために作成されます。

Lambda 統合機能: apigw-sap-idoc-s3という名称のNode.jsのLambda関数が作成され、SAPから受信したIDocペイロードを前に作成されたS3 バケットに格納します。

IAMロール: Lambda関数に対して2つのロールが作成されます。

  • Amazon Cognitoに対する管理者としての認証アクセスをLambda オーソライザー機能に提供するために、<Environment>-lambda-authorizer-roleという名称のロール (例えば、sapidocs-lambda-authorizer-roleなど)が作成されます。
  • IDocを格納するためのS3 バケットへの書き込みアクセスを提供するために、<Environment>-lambda-s3-access-policyという名称のロール (例えば、sapidocs-lambda-s3-access-policyなど)を作成します。

Amazon API Gateway API: sap-idoc-adapter-apiという名称のAmazon API Gateway APIが作成されます。このAPI用に、IDOC_Adapter_Authorizerという名称のLambda オーソライザー (「リクエスト」ベース)も作成されます。このAPIにはGETメソッドとPOSTメソッドがあります。これらの方法はどちらも認証にLambda オーソライザーを使用します。GETメソッドはモックのエンドポイントを対象としており、SAPアプリケーションからの接続と許可をテストするためにのみ使用されます。POSTメソッドは、IDocペイロードデータをSAPアプリケーションからS3 バケットにアップロードするためのLambda関数apigw-sap-idoc-s3を呼び出すことによってLambda統合を使用します。

リソース制限

  • Amazon API Gatewayの制限と重要な注意点、特にペイロードサイズの制限 (書き込み時には10MB)と統合タイムアウト (書き込み時には29秒)に注意してください。IDocをバッチ処理すると、ペイロードサイズが大きくなったり処理時間が長くなったりする可能性があり、タイムアウトになる可能性があります。もっと小さいバッチサイズを検討したくなるかもしれません。
  • AWS Lambdaの制限に注意してください。呼び出しペイロードのサイズとメモリ割り当てには制限があり、これもIDocのバッチサイズに影響を与える可能性があります。

終わりに

このブログ記事では、セキュリティ上のベストプラクティスを取り入れながら、SAPアプリケーションをコーディングすることなくAmazon S3にSAP IDocデータをアップロードする方法を紹介しました。APIは、Amazon Cognitoによるユーザー認証、およびIAMポリシーによるユーザー許可によって保護されています。これで、品目マスターなどのSAPマスターデータを、AWS上で稼働している他のアプリケーションと統合できます。銀行と財務データを統合するなど、B2B統合も実現できます。

このアプローチはほとんどのユースケースで有効です。しかしながら、ABAP HTTPクライアントライブラリを使用したSAPアプリケーションのカスタムコーディングを保証するためには、極端に十分な大きさになってしまう可能性があるという危険なケースがあります。そのような場合には、サードパーティのアダプターをチェックするか、独自のABAP HTTPクライアントライブラリを構築することをお勧めします。

このブログ記事が役に立つことを願っています。コメントや質問がある場合、お気軽に私たちに連絡してください。

翻訳はPartner SA 河原が担当しました。原文はこちらです。