ESとBAPIと比較するのは、少々無理がある
ところが、ESをBAPIと比較することで理解するのは、思った以上に難しい。難しい理由を3つ挙げてみよう。
- BAPIよりもESのほうがインタフェースパターンが多い
- BAPIの "inside-out" に対して、ESは "outside-in" の考え方で設計されている
- BAPIはABAP Stack(いわゆるBASIS)に定義と実装が集約されているが、ESはESRやABAP/Java stacksなどに分散している
1. BAPIよりもESのほうがインタフェースパターンが多い
BAPIは外部から同期的にコールするインタフェースだけだが、ESは同期 / 非同期にそれぞれinbound / outboundの、4通りの組み合わせがある。BAPIとの比較では 同期 かつ inboundだけが注目されることになり、他の3パターンは比較対象から外れてしまう。
この図は、Business Object (BO)を中心に据えて、ESのサービスインタフェースとその下位層のサービスオペレーションを4方向に配置したものだ。BOの左から右に同期的なサービスインタフェースが、上から下に非同期的なサービスインタフェースがモデルとして表現されている。
BOを中心として時計の針9時の位置が「同期的なinbound」、3時が「同期的なoutbound」だ。また12時が「非同期的なinbound」、6時が「非同期的なoutbound」である。以下、時計の針の位置でサービスのパターンを呼ぼう。
BAPIはこの9時のパターンしかなく、12時、3時、6時の理解をするためにはIDocやイベント処理などとも比較する必要があることを、まずは理解したい。
2. BAPIの "inside-out" に対して、ESは "outside-in" の考え方で設計されている
システム内部のプログラムを呼び出す仮引数を、そのまま外部からも呼び出し可能なように外に出すことを "inside-out" と呼んでいる。SAP BASIS的に表現するならば、汎用モジュールのパラメータをそのままリモートからも使えるようにした、ということだ。
従って、ABAPに長けているエンジニアには、内部テーブルの項目に一対一対応しているBAPIのパラメータは理解が容易だ。
この図は、受注伝票を登録するBAPI "CreateFromDat2" のパラメータをリスト化したもので、伝票ヘッダの実引数は BAPISDHD1 という構造に代入することになることがわかる。
さらにこの BAPISDHD1 をダブルクリックすると、次のような構造照会が表れる。
たとえば項目 SALES_ORG は、内部では VKORG なんだなと判るとそれが安心材料になる*1。このように "inside-out" は、内部構造を知るエンジニアがプログラミングしやすいようになっている。
一方、ESは "outside-in" の考え方で定義されている。"inside-out"が、内部構造を知るエンジニアが使いやすいとするならば、その反対で、ビジネスを知るユーザが使いやすいようにできているはず。BAPI "CreateFromDat2" に対比されうる ES "Create Sales Order_V2" で確認してみよう。
ESの設計情報はSAP Community Network (SCN)の ES Workplace に開示されていて、誰でも参照可能だ。
"Create Sales Order_V2"
| Software Component Version | SAP APPL 6.04 | 6.04はEhP4で有効であることを示す | ||
| Technical Name | SalesOrderERPCreateRequestConfirmation_In_V2 | エンドポイントのWebサービス名称 | ||
| Namespace | http://sap.com/xi/APPL/Global2 | ESR内部のネームスペース | ||
| Direction | inbound | |||
| Mode | synchronous | 同期的なinboundサービスは9時の位置 | ||
| First released with: Shipment Release | SAP APPL 6.03 | _v2はEhP3でリリースされた | ||
| Release Status | released | 利用可能 | ||
| Application Component | SD-SLS-ES | 保守などで用いる分類 | ||
| Change/Update Behavior | not applicable | *2 | ||
| Idempotency | Yes | *3 | ||
| Business Function | LOG_ESOA_OPS_2, PSM_ESOA_SDINT | *4 | ||
| Related Web Service Definition | ECC_SALESORDERERPCRTRC2 | SOAPランタイム名称 |
このTechnical Dataの次に、文章でこのESの使い方が記述されているところが "outside-in" たる所以だ。ただ、現時点、英語でしか記述されていないところが我々日本人にとってのハードルだ。残念ながら、まだ日本語化の予定は聞いていない。
Business Context and Use
A sales order is an agreement between a seller and a customer concerning the sale and delivery of goods, as well as any services that are associated with these processes, on a specific date, for a specific quantity, and for a specific price. With the Create Sales Order_V2 inbound operation you can create a document covering all these details to ensure smooth workflow.
以下、古澤の私訳。
ビジネスの前後関係と用途について
受注とは、売り手と買い手との間で締結される販売と、それに伴う商品の配送もしくはサービスの提供に関する契約の一種であり、特定の日付、特定の数量、そして特定の価格の決定プロセスがそれに関係する。"Create Sales Order_V2"のインバウンドオペレーションを用いて、これらの詳細情報を網羅した伝票を作成でき、スムーズなワークフローを走らせることが出来る。
その後段で、AFS (アパレル・フットウェア・ソリューション)に関係した受注も受けられることや、機能詳細が文章で述べられている。
Versioning の項では、引合い、見積り、別の受注、契約、請求など別の伝票類を参照して受注伝票を作ることができるようになったとある。
また、Configrationの項では、SDアプリケーションに対するESを導入することと、そのSDの受注に関するパラメータセッティングを完了済みであることを求めている。
時々、これまでどおりERPのパラメータ設定を行わないと ES が使うことが出来ないことを知って、愕然とされるお客様がいらっしゃる。考えてみると設定が必要なのは当たり前のことで、入出力をSAP GUIからやろうが、ESを介してブラウザから行おうが、サーバ側に会社という概念（この場合は会計・販売管理・在庫管理に関する「会社の構造」）が正しくモデル化され、かつマスタ類も自社に必要なだけ登録済みでないと、サービスは正しく動かない。サービスのエンドポイントでは、ABAPプログラムがパラメータ設定に従って動いているということを理解すべきだ。
さて、これらの説明文書がビジネスを知るユーザに有効かどうか、というと、現実はそうではなく、やはりエンジニア向けなのだろう。それでもできるだけ、どういう用途にこのESは適用可能なのか、と言う視点で文書化がなされていることがSAPらしい。
さて、ESのサービスオペレーションの項目だが、それの確認の方法は以前の記事「ESワークプレイスを使ってみよう」に記載してあるので、その方法を使ってWSDLをチェックしてみてほしい。
3. BAPIはABAP Stack(いわゆるBASIS)に定義と実装が集約されているが、ESはESRやABAP/Java stacksなどに分散している
お客様と会話をしていると、いつもこの点で見通しが悪くなる。BAPIならば/nBAPIを介して情報を全部把握できるのに対して、ESの場合は、定義が複数箇所に分散しているからだ。元の定義はSAP NetWeaver PIもしくはCEのESR内でモデリングされる。そこからService RegistryにpublishされたWSDLはコンポジットアプリケーション開発時やBPMのモデリング時に参照される。また、サービスのエンドポイントでは、このWSDLを用いてproxyを生成した後に、ABAPやJavaを用いて実際のロジックを開発することになる。
またESに関する文書は前述のとおり、ES Workplaceに記載されている。
定義を確認して適切なESを選ぶならES Workplace、ESを定義するならESR、ESを使ってアプリケーションやプロセスをモデリングする場合にはService Registryがそれぞれ必要であることを覚えておこう。
*1:VB**というテーブル名やVK***という項目名を見て、あぁSD受注系なんだなと思う方にとって、このあたりは当たり前すぎることを書いてます。ちなみにVBはドイツ語の Verkaufsbeleg をSAP流に略したもののようで、英語では Sales Document、日本語なら 受注伝票に相当します。
*2:このサービスは「登録」なので適用外。「更新」の場合、"type 3"が指定されていることがある。
*3:Idempotent Serviceであること。Idempotentとは、冪等(べきとう)という日本語が当てられている。「その操作を何回繰り返しても、1回だけ実行した時と同じ結果になるもの」
