I had published an article with the same content in Japanese only, but several people asked me to publish it in English as well, so I created an English version.
As published by Rama-murari, SAP Build Apps has new functionality to work with SAP Build Process Automation.
However, there are conditions for using this functionality. That is that the SAP Build Process Automation process must use API Trigger. This new method cannot be used for form triggers.
Changing a process from Form Trigger to Process Trigger is not that difficult, but it still seems that customers are not comfortable with the change or with creating two versions of the same process.
This section explains how to link form triggers if they are used there.
Preliminary tasks
Step 1.Availability of a service instance of SAP Build Process Automation
Check whether a service instance of SAP Build Process Automation has been created. It is not a subscription. To check whether a service instance has been created, go to the BTP Cockpit and check the list of instances from the sub-accounts Instances and Subscriptions. This is not a list of subscriptions. List of instances.
If Service:SAP Build Process Automation and Plan:Standard exist here, the instance exists. If it does not exist, click on the Create button
Select Standard for “Instances” in Plan to create an instance.
*Note that there is no charge for this instance, which is treated as ‘incidental to subscription’. This instance enables API access to SAP Build Process Automation. It is therefore meaningless if SAP Build Process Automation is not subscribed.
After creating the instance, issue a service key. Use the contents of the service key at Step 2.
Step2. Creating Destinations to access SAP Build Process Automation APIs.
You need to create a sub-account Destination for the BTP Cockpit using the information in the service key of the instance created in Step1.
Name:<free>
Type:HTTP
Description:.
URL: <value of endpoints/api in service key information in 1>.
Proxy Type:Internet
Authentication: OAuth2JWTBearer
Client ID: <value of uaa/clientid in service key information in 1
Client Secret: <value of uaa/clientsecret in service key information in 1
Token Service URL Type: Dedicated
Token Service URL:<add /oauth/token to the value of uaa/url in the service key information of 1>.
Set the following as Additional Properties.
HTML5.DynamicDestination=true
WebIDEEnabled=true
MobileEnabled=true
sap.processautomation.enabled=true
Appgyver.Enabled=true
sap.applicationdevelopment.actions.enabled=true
Note 1: Correctly, Destination is not mandatory. However, without Destination, the authentication part has to be written as logic on the Build Apps side, which can be quite a hassle. By using Destination, these tasks can be skipped and you can just call the API.
Note2:If a Destination named “sap_process_automation_service_user_access” exists – which created by booster, you can use it .
Work on the SAP Build Process Automation side
Create a process triggered by the form trigger. An existing process can also be used. There are no restrictions, but if forced, forms with file attachments can be a bit tricky. This will be explained later in another blog, so for now, if you are working with this article, do not use forms with file attachments as trigger forms.
The tricky part is that SAP Build Process Automation’s file attachment functionality stores files in the SAP Document Management Service.If you use SAP Build Apps as a trigger, you must access the Document Management Service to store the files. This part alone is enough to write a whole article, so we would like to leave it as a separate explanation.
And the key task is to start this process once, normally, with the trigger form. You need to actually put values in all the fields of the trigger form and submit it.
Then, from the SAP Build lobby, go to Monitoring -> Process and Workflow instances to see which workflow instance you are running and check the Context information.
Note the entry under the entry named “startEvent”. This is the value passed in the trigger form.
This is the same type of information that needs to be given when executing the SAP Build Process Automation API from the SAP Build Apps side, so copy the context information.
Now that you have opened the SAP Build lobby, you should also go to Monitoring, Process and Workflow Definitions, select the workflow you want to link to and store the value of the ID field. This value is also required when executing the API.
Work on the SAP Build Apps side
BTP authentication is mandatory as Destination is used.
The API to execute the workflow is executed in REST format, so you should use “SAP BTP Destination REST API Integration”.
In the data integration settings on the DATA tab, select SAP BTP Destination REST API Integration under SAP Build Apps classic data entities.
Set the Data entity name as desired and select the Destination prepared in Preparation Step2 for the BTP Destination name.
Here, there is a matter of preference, but set the ResourceSchema to be treated explicitly as an argument when calling this API.
The content to be set is what is included in the startEvent field of the context obtained by running the workflow on the SAP Build Process Automation side. As an example, the process I ran was as follows.
“startEvent”: {
“itemNumber”: “AAAA”,
“itemName”: “LAPTOP1”,
“price”: 799.99
}
These three are found in the startEvent field, so set these three.
The data type must match the workflow side of SAP Build Process Automation. Set the data type of the field in the trigger form as a reference.
The API to run the workflow is https://api.sap.com/api/SPA_Workflow_Runtime/path/post_v1_workflow_instances
/v1/workflow_instances (start a new instance）
Since this is required to be done via POST, we will use the Create method on the Build Apps side: activate the switch button next to create.
As API, you will call “/v1/workflow_instances”, but the endpoint will be “/public/workflow/rest/v1/workflow-instances”.
Set additional parameters for Relative path and query and add “/public/workflow/rest/v1/workflow-instances” as Static Text.
This API requires the content of the BODY to be sent in JSON, so set Content-Type : application/json in the Request Headers. This is set in the Request Headers setting.
Select the List of Values and
Set by writing directly.
The BODY part must be transmitted in JSON. To ensure that it is sent in JSON
Use an expression in the Request Body Mapper and set it using the ENCODE_JSON function.
Set up as follows. In the format.
ENCODE_JSON({“definitionId”:”<value of the ID of the previously obtained workflow>”, “context”: {<all parameters present in startEvent>}})
You can set them up as above.
Variables set in ResourceSchema can be referenced in query.record.<variable name>.
A point to note is that the ENCODE_JSON function does not seem to look at the data type of the variables used in it. Therefore, if you use a numeric type, specify it explicitly as a number type using the NUMBER function as shown in the screenshot (“price”:NUMBER(query.record.price)). If this is not done, the data is passed as a string enclosed in double quotes as an argument to the API, resulting in an error when the workflow is executed that the data type does not match.
This completes the data linkage settings for running the workflow.
All that remains is to call it.
Create logic for buttons etc.
Connect Create Record logic,
Specify the Resource Name of the property as the Resource Name of the data linkage configuration you have just created; if you have set up a Resource Schema, you can use it in the Record settings.
This is useful because the parameters can be specified in this straightforward manner.
By setting values such as Input Field here, it is submitted and the SAP Build Process Automation workflow process is triggered.
From the SAP Build Process Automation side, the trigger form is replaced by the Build Apps application. Therefore, the process starts working from the next logic of the trigger form.
What is not possible with SAP Build Process Automation forms, e.g.
If you want to select such a category to narrow down your application to a product, or to narrow down your application to a major category, then a medium category, then a minor category, then a product, you can take the approach of creating a trigger in Build Apps.
If you want more flexibility with your SAP Build Process Automation forms, you should definitely consider using SAP Build Apps.
I had published an article with the same content in Japanese only, but several people asked me to publish it in English as well, so I created an English version.As published by Rama-murari, SAP Build Apps has new functionality to work with SAP Build Process Automation.However, there are conditions for using this functionality. That is that the SAP Build Process Automation process must use API Trigger. This new method cannot be used for form triggers.Changing a process from Form Trigger to Process Trigger is not that difficult, but it still seems that customers are not comfortable with the change or with creating two versions of the same process.This section explains how to link form triggers if they are used there.Preliminary tasksStep 1.Availability of a service instance of SAP Build Process Automation Check whether a service instance of SAP Build Process Automation has been created. It is not a subscription. To check whether a service instance has been created, go to the BTP Cockpit and check the list of instances from the sub-accounts Instances and Subscriptions. This is not a list of subscriptions. List of instances.If Service:SAP Build Process Automation and Plan:Standard exist here, the instance exists. If it does not exist, click on the Create buttonSelect Standard for “Instances” in Plan to create an instance.*Note that there is no charge for this instance, which is treated as ‘incidental to subscription’. This instance enables API access to SAP Build Process Automation. It is therefore meaningless if SAP Build Process Automation is not subscribed.After creating the instance, issue a service key. Use the contents of the service key at Step 2.Step2. Creating Destinations to access SAP Build Process Automation APIs.You need to create a sub-account Destination for the BTP Cockpit using the information in the service key of the instance created in Step1.Name:<free>Type:HTTPDescription:.URL: <value of endpoints/api in service key information in 1>.Proxy Type:InternetAuthentication: OAuth2JWTBearerClient ID: <value of uaa/clientid in service key information in 1Client Secret: <value of uaa/clientsecret in service key information in 1Token Service URL Type: DedicatedToken Service URL:<add /oauth/token to the value of uaa/url in the service key information of 1>.Set the following as Additional Properties.HTML5.DynamicDestination=trueWebIDEEnabled=trueMobileEnabled=truesap.processautomation.enabled=trueAppgyver.Enabled=truesap.applicationdevelopment.actions.enabled=trueNote 1: Correctly, Destination is not mandatory. However, without Destination, the authentication part has to be written as logic on the Build Apps side, which can be quite a hassle. By using Destination, these tasks can be skipped and you can just call the API.Note2:If a Destination named “sap_process_automation_service_user_access” exists – which created by booster, you can use it .Work on the SAP Build Process Automation sideCreate a process triggered by the form trigger. An existing process can also be used. There are no restrictions, but if forced, forms with file attachments can be a bit tricky. This will be explained later in another blog, so for now, if you are working with this article, do not use forms with file attachments as trigger forms.The tricky part is that SAP Build Process Automation’s file attachment functionality stores files in the SAP Document Management Service.If you use SAP Build Apps as a trigger, you must access the Document Management Service to store the files. This part alone is enough to write a whole article, so we would like to leave it as a separate explanation.And the key task is to start this process once, normally, with the trigger form. You need to actually put values in all the fields of the trigger form and submit it.Then, from the SAP Build lobby, go to Monitoring -> Process and Workflow instances to see which workflow instance you are running and check the Context information.Note the entry under the entry named “startEvent”. This is the value passed in the trigger form.This is the same type of information that needs to be given when executing the SAP Build Process Automation API from the SAP Build Apps side, so copy the context information.Now that you have opened the SAP Build lobby, you should also go to Monitoring, Process and Workflow Definitions, select the workflow you want to link to and store the value of the ID field. This value is also required when executing the API.Work on the SAP Build Apps sideBTP authentication is mandatory as Destination is used.The API to execute the workflow is executed in REST format, so you should use “SAP BTP Destination REST API Integration”.In the data integration settings on the DATA tab, select SAP BTP Destination REST API Integration under SAP Build Apps classic data entities.Set the Data entity name as desired and select the Destination prepared in Preparation Step2 for the BTP Destination name.Here, there is a matter of preference, but set the ResourceSchema to be treated explicitly as an argument when calling this API.The content to be set is what is included in the startEvent field of the context obtained by running the workflow on the SAP Build Process Automation side. As an example, the process I ran was as follows.”startEvent”: {“itemNumber”: “AAAA”,”itemName”: “LAPTOP1″,”price”: 799.99}These three are found in the startEvent field, so set these three.The data type must match the workflow side of SAP Build Process Automation. Set the data type of the field in the trigger form as a reference.The API to run the workflow is https://api.sap.com/api/SPA_Workflow_Runtime/path/post_v1_workflow_instances/v1/workflow_instances (start a new instance）Since this is required to be done via POST, we will use the Create method on the Build Apps side: activate the switch button next to create.As API, you will call “/v1/workflow_instances”, but the endpoint will be “/public/workflow/rest/v1/workflow-instances”.Set additional parameters for Relative path and query and add “/public/workflow/rest/v1/workflow-instances” as Static Text.This API requires the content of the BODY to be sent in JSON, so set Content-Type : application/json in the Request Headers. This is set in the Request Headers setting.Select the List of Values andSet by writing directly.The BODY part must be transmitted in JSON. To ensure that it is sent in JSONUse an expression in the Request Body Mapper and set it using the ENCODE_JSON function.Set up as follows. In the format.ENCODE_JSON({“definitionId”:”<value of the ID of the previously obtained workflow>”, “context”: {<all parameters present in startEvent>}})You can set them up as above.Variables set in ResourceSchema can be referenced in query.record.<variable name>.A point to note is that the ENCODE_JSON function does not seem to look at the data type of the variables used in it. Therefore, if you use a numeric type, specify it explicitly as a number type using the NUMBER function as shown in the screenshot (“price”:NUMBER(query.record.price)). If this is not done, the data is passed as a string enclosed in double quotes as an argument to the API, resulting in an error when the workflow is executed that the data type does not match.This completes the data linkage settings for running the workflow.All that remains is to call it.Create logic for buttons etc. Connect Create Record logic,Specify the Resource Name of the property as the Resource Name of the data linkage configuration you have just created; if you have set up a Resource Schema, you can use it in the Record settings.This is useful because the parameters can be specified in this straightforward manner.By setting values such as Input Field here, it is submitted and the SAP Build Process Automation workflow process is triggered.From the SAP Build Process Automation side, the trigger form is replaced by the Build Apps application. Therefore, the process starts working from the next logic of the trigger form.What is not possible with SAP Build Process Automation forms, e.g.If you want to select such a category to narrow down your application to a product, or to narrow down your application to a major category, then a medium category, then a minor category, then a product, you can take the approach of creating a trigger in Build Apps.If you want more flexibility with your SAP Build Process Automation forms, you should definitely consider using SAP Build Apps. Read More Technology Blogs by SAP articles
#SAP
#SAPTechnologyblog
+ There are no comments
Add yours