Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
cancel
Showing results for 
Search instead for 
Did you mean: 
NaotoSakai
Advisor
Advisor

※この記事を書いている間にSAP Build Appsに新しい機能がリリースされました。通常はそちらの方法をおすすめします。そちらの機能の解説はこちらです。
この記事はSAP Build Process Automation側でプロセスのトリガーとしてフォームを使用している場合、そしてそれをAPIトリガーに変更することが困難な場合に適用できる方法としてご紹介したいと思います。

SAP Build AppsのアプリケーションからSAP Build Process Automationのワークフローを呼び出したいというときがあります。結論から言うとこれはワークフローをAPI経由で起動させることで可能です。これを行うには前準備作業が必要です。

前準備作業

1.SAP Build Process Automationのサービスインスタンスの有無
 SAP Build Process Automationのサービスインスタンスが作成されているか確認してください。サブスクリプションでは有りません。サービスインスタンスが作成されているかはBTPコックピットでサブアカウントのInstances and Subscriptionsからインスタンスの一覧を確認します。サブスクリプションの一覧では有りません。インスタンスの一覧です。

NaotoSakai_0-1714105109930.png
ここにService:SAP Build Process Automation、Plan:Standardが存在すればインスタンスが存在していることになります。存在しない場合はCreateボタンから

NaotoSakai_1-1714105272941.png
PlanでInstancesのStandardを選択してインスタンスを作成してください。

※なお、このインスタンスの料金は「サブスクリプションに付随するもの」という扱いで無料です。このインスタンスはSAP Build Process Automationに対してAPIでのアクセスを可能にするものです。よってSAP Build Process Automationがサブスクライブされていないと意味がありません。

インスタンスを作成したらサービスキーを発行してください。サービスキーの中身を2で使用します。

2.SAP Build Process AutomationのAPIへアクセスするDestinationの作成
1で作成したインスタンスのサービスキーの情報を利用してBTPコックピットのサブアカウントDestinationを作成する必要があります。

Name: <自由です>

Type:HTTP
Description:
URL: <1のサービスキー情報のendpoints/apiの値>
Proxy Type:Internet
Authentication: OAuth2JWTBearer
Client ID: <1のサービスキー情報のuaa/clientidの値>
Client Secret: <1のサービスキー情報のuaa/clientsecretの値>
Token Service URL Type: Dedicated
Token Service URL:<1のサービスキー情報のuaa/urlの値に/oauth/tokenを追加>
Additional Propertiesとして下記を設定します。
HTML5.DynamicDestination=true
WebIDEEnabled=true
MobileEnabled=true
sap.processautomation.enabled=true
Appgyver.Enabled=true
sap.applicationdevelopment.actions.enabled=true

注意1:正しくはDestinationは必須ではありません。しかし、Destinationを使用しないと認証部分をBuild Apps側でロジックとして書かなければならなくなります。これは結構めんどくさい作業です。Destinationを使用することでそれらの作業をスキップすることが可能で、APIを呼び出すだけとすることができます。
注意2:こちらの記事で作成した/あるいはブースターで作成されたsap_process_automation_service_user_accessというDestinationが存在する場合、それをそのまま使用することができます。

SAP Build Process Automation側の作業

フォームをトリガーとしたプロセスを作成してください。既存のプロセスでも良いでしょう。特に制限はありませんが、強いてあげると、ファイル添付機能を持ったフォームは少々厄介です。これは後で別のブログで解説しようかと思いますので今のところはこの記事に沿った作業を行う場合はファイル添付を行うフォームをトリガーフォームとして使用しないようにしてください。

厄介な部分として、SAP Build Process Automationのファイル添付機能はSAP Document Management Serviceにファイルが保存されます。SAP Build Appsをトリガーとして使用する場合、SAP Build AppsからDocument Management Serviceにアクセスしてファイルを保管する事が必要です。この部分だけで1本記事が書けるレベルですので別解説とさせていただければと思います。

そして、ポイントとなる作業ですが、まずこのプロセスを一度普通に、トリガーフォームから開始してください。トリガーフォームの全ての項目に実際に値を入れて送信してください。
その後、SAP BuildのロビーからMonitoring→Process and Workflow instancesと進み、実行しているワークフローのインスタンスを確認し、Contextの情報を確認します。

NaotoSakai_0-1714116424474.png

startEventというエントリの下にある項目に注目です。これがトリガーフォームで渡された値です。
これと同じ形式の情報をSAP Build Apps側からSAP Build Process AutomationのAPIを実行する際に付与する必要がありますのでコンテキスト情報をコピーしておいてください。
SAP Buildのロビーを開きましたのでもう一つ、同じくMonitoringからProcess and Workflow Definitionsと進み、連携させるワークフローを選択してIDという項目の値を保管しておいてください。この値もAPI実行時に必要です。

NaotoSakai_1-1714116965132.png

SAP Build Apps側での設定

Destinationを使用するためBTP認証は必須となります。
ワークフローを実行するAPIはREST形式で実行しますので

NaotoSakai_0-1714441977707.png

DATAタブでのデータ連携設定ではSAP Build Apps classic data entitiesの下にあるSAP BTP Destination REST API Integrationを選択します。
Data entity nameは任意に設定し、BTP Destination nameは前準備2で準備したDestinationを選択します。

NaotoSakai_1-1714442286574.png

ここで、好みの問題がありますが、このAPIを呼び出すときに引数として明確に扱われるようにResourceSchemaを設定します。

NaotoSakai_2-1714443051507.png

設定する内容はSAP Build Process Automation側でワークフローを実行し、取得したコンテキストのstartEventフィールドに含まれているものを設定します。例として

"startEvent": {
"itemNumber": "AAAA",
"itemName": "LAPTOP1",
"price": 799.99
}

このようにstartEventフィールドに有りましたのでこの3つを設定します。

NaotoSakai_3-1714443909336.png

データ型はSAP Build Process Automationのワークフロー側に合わせる必要があります。トリガーフォームでのフィールドのデータ型を参考にして設定してください。

ワークフローを実行するAPIはhttps://api.sap.com/api/SPA_Workflow_Runtime/path/post_v1_workflow_instances
の/v1/workflow_instancesです。(複数ありますが、start a new instanceと書いてあるものです。)
これはPOSTで実行することが求められていますので、Buils Apps側ではCreateメソッドを用いることにします。create横のスイッチボタンを有効化します。

NaotoSakai_4-1714444802633.png

APIとしては/v1/workflow_instanceを呼び出すことになるのですが、エンドポイントとしては/public/workflow/rest/v1/workflow-instancesとなります。Relative path and queryに追加のパラメータを設定し、Static Textとして/public/workflow/rest/v1/workflow-instancesを追加します。

NaotoSakai_0-1714449665776.png

このAPIはBODYの内容をJSONで送信する必要がありますのでRequest HeadersにContent-Type : application/jsonを設定します。これはRequest Headersの設定で

NaotoSakai_6-1714445268503.png

List of Valuesの方を選択し

スクリーンショット 2024-04-30 10.47.00.png

直接書き込むことで設定します。

BODY部分はJSONで送信する必要があります。確実にJSONで送信されるように
Request Body Mapperで式を用い、ENCODE_JSON関数を用いて設定します。

NaotoSakai_7-1714445896779.png

以下のように設定します。書式としては

ENCODE_JSON({"definitionId":"<事前に取得したワークフローのIDの値>","context": {<startEventに存在する全てのパラメータ>}})

とおぼえておけばよいでしょう。ResourceSchemaで設定した変数はquery.record.<変数名>で参照することができます。
ポイントとして、ENCODE_JSON関数は中で使用された変数のデータ型までは見てくれないようです。そのため、数値型を使用する場合はスクリーンショットのようにNUMBER関数を用いて明示的に数字型として指定して下さい( "price":NUMBER(query.record.price) )。これを行わないと文字列としてダブルクォーテーションで囲まれた状態でAPIに引数として渡され、ワークフローの実行時にデータ型が合わないというエラーになります。

これでワークフローを実行するためのデータ連携設定が完了しました。
あとはこれを呼び出すだけとなります。
ボタンなどにロジックを作成します。

NaotoSakai_1-1714450375078.png

Create Recordロジックを接続し、

NaotoSakai_2-1714450459037.png

プロパティのResource Nameとして先ほど作成したデータ連携設定のものを指定します。Resource Schemaを設定してあればRecordの設定で

NaotoSakai_3-1714450541102.png

このようにわかりやすくパラメータを指定できるので便利です。
Input Fieldなどの値をここに設定することでそれが送信されて、SAP Build Process Automationのワークフロープロセスが起動します。

SAP Build Process Automation側から見るとトリガーフォームがBuild Appsのアプリケーションに入れ替わった形となります。したがってプロセス上はトリガーフォームの次のロジックから動作し始めるということになります。

SAP Build Process Automationのフォームでは不可能なこと、例えば

NaotoSakai_4-1714450882880.png

このようなカテゴリを選んで製品を絞り込んで申請する、大分類→中分類→小分類→製品と絞り込みたいという場合、トリガーをBuild Appsで作成するという手法を取ることができます。

SAP Build Process Automationのフォームにより自由度を持たせたいという場合はSAP Build Appsの使用もぜひ検討して下さい。