- SAP Managed Tags:
In this three part blog series (part 2, part 3), I'll demo how SAP Build can be used to quickly develop an application using a side by side extensibility pattern with SAP S/4HANA Cloud, public edition (which I'll refer to as S/4HC). In this first blog, I'll outline the API setup and iFlow creation using BTP Cloud Integration. SAP Build will be used in the second and third blogs. In the next blog I will cover the steps to create an Action Project and Workflow Approval Process using SAP Build Process Automation (SBPA). In the the final blog, I will demo the creation of a UI on SAP Build App for end users to enter new project data on their device.
In the demo, there is a requirement to have employees working in the field create commercial projects in SAP S/4HANA Cloud, public edition for new projects based on a minimal set of data (project name, customer, cost and profit center and dates). The end user would enter these fields quickly for new projects into a simple UI. The projects should be approved by a manager before being created in S/4HC. Every new project that gets created via this process should also have 3 default work packages set up for project tracking purposes: Project Kickoff, Execution and Burden.
Ideally, the Process Automation would call the API in S/4HC directly, however at the time of writing this blog, there is a restriction in SBPA that it does not support nested actions, which we would need to add the work packages to the API call for S/4HC (header/child elements).
The commercial projects API uses Communication Scenario SAP_COM_0054. The process to expose the API for BTP CI is straightforward and documented many times over already in the community. You can find the steps here.
As a workaround to the aforementioned restriction, I decided to use BTP Cloud Integration (CI) to expose a REST endpoint that SBPA can call. I chose this approach versus trying to script something in SBPA because I wanted to avoid writing code and trying to adopt a low code approach. The other nice thing about using CI is that I can use the robust mapping functionality available to add the header level default fields (i.e. company code, project type, etc) and also the 3 work packages. The iFlow development is fairly straightforward for something this simple.
The end user will ultimately enter the following data in the Build App so this is the JSON payload that is our starting point for the REST API.
I need an XSD for this JSON in order to perform the mapping. Normally, I would create this by hand but now I can use chatGPT for this:
Now, to build the iFlow. Create a new REST integration on BTP CI which automatically adds the HTTP sender channel. I add the endpoint name "/createproject", which will be the endpoint called from SBPA.
Next, I add a converter to convert JSON to XML for use in our mapping step and use the XSD generated above.
Next, I will add a Request/Reply call to S/4HC to the integration flow. Doing so allows me to generate the S/4HC XSD needed in the mapping step. I select all fields from the projects API that I need, including the workpackage entity.
Now it is time to perform the message mapping where I use several methods. The first is a simple left to right mapping of source to target:
I also set constants for what are essentially hardcoded values that will not change for this user group when creating a project. You could also externalize these values so they could be set via configuration on the iFlow as well.
Within here, I can also format the date correctly to append "T00:00:00" and also set the work package IDs correctly using concat functions:
Finally, for the purposes of this demo I will return a simple payload back to the caller upon successful call of this API. I just use a Content Modifier to set the message body back to the original payload. This results in the following simple iFlow, which again is for a demo and doesn't have validations, error handling, etc.
I can now deploy the iFlow and test the REST API from Postman. Upon testing, I receive a successful 201 reply with the JSON payload as a response.
Executing the integration with status TRACE, I can view the mapping payload. This is the mapped payload that was used for the API call to S/4HC.
The project in S/4HC and it is ready to be used with the correct structure.
Now that we have a working REST API on BTP Cloud Integration, we are ready to start building the low code app using SAP Build tools. I'll cover this process in the next two blogs.
Thanks,
Marty
Scenario
In the demo, there is a requirement to have employees working in the field create commercial projects in SAP S/4HANA Cloud, public edition for new projects based on a minimal set of data (project name, customer, cost and profit center and dates). The end user would enter these fields quickly for new projects into a simple UI. The projects should be approved by a manager before being created in S/4HC. Every new project that gets created via this process should also have 3 default work packages set up for project tracking purposes: Project Kickoff, Execution and Burden.
Ideally, the Process Automation would call the API in S/4HC directly, however at the time of writing this blog, there is a restriction in SBPA that it does not support nested actions, which we would need to add the work packages to the API call for S/4HC (header/child elements).
Create REST API using SAP BTP Cloud Integration
SAP S/4HANA Cloud Configuration
The commercial projects API uses Communication Scenario SAP_COM_0054. The process to expose the API for BTP CI is straightforward and documented many times over already in the community. You can find the steps here.
BTP Cloud Integration iFlow
As a workaround to the aforementioned restriction, I decided to use BTP Cloud Integration (CI) to expose a REST endpoint that SBPA can call. I chose this approach versus trying to script something in SBPA because I wanted to avoid writing code and trying to adopt a low code approach. The other nice thing about using CI is that I can use the robust mapping functionality available to add the header level default fields (i.e. company code, project type, etc) and also the 3 work packages. The iFlow development is fairly straightforward for something this simple.
The end user will ultimately enter the following data in the Build App so this is the JSON payload that is our starting point for the REST API.
{
"Customer": "1000185",
"ProjectName": "PROCPROJAPF1",
"ProjectID": "PROCPROJAPDF1",
"ProjManagerExtId": "I805828",
"StartDate": "2023-04-29",
"CostCenter": "0017101902",
"ProfitCenter": "YB101",
"EndDate": "2024-04-29",
"ProjectDesc": "PROCPROJAPF1 desc"
}I need an XSD for this JSON in order to perform the mapping. Normally, I would create this by hand but now I can use chatGPT for this:
Using chatGPT to generate XSD schema file
Now, to build the iFlow. Create a new REST integration on BTP CI which automatically adds the HTTP sender channel. I add the endpoint name "/createproject", which will be the endpoint called from SBPA.
REST endpoint /createproject
Next, I add a converter to convert JSON to XML for use in our mapping step and use the XSD generated above.
JSON to XML Converter
Next, I will add a Request/Reply call to S/4HC to the integration flow. Doing so allows me to generate the S/4HC XSD needed in the mapping step. I select all fields from the projects API that I need, including the workpackage entity.
API call to S/4HC
Now it is time to perform the message mapping where I use several methods. The first is a simple left to right mapping of source to target:
Left to Right Mapping
I also set constants for what are essentially hardcoded values that will not change for this user group when creating a project. You could also externalize these values so they could be set via configuration on the iFlow as well.
Hardcoded Mapping
Duplicate Nodes
Within here, I can also format the date correctly to append "T00:00:00" and also set the work package IDs correctly using concat functions:
Work Package ID
Finally, for the purposes of this demo I will return a simple payload back to the caller upon successful call of this API. I just use a Content Modifier to set the message body back to the original payload. This results in the following simple iFlow, which again is for a demo and doesn't have validations, error handling, etc.
Demo iFlow
I can now deploy the iFlow and test the REST API from Postman. Upon testing, I receive a successful 201 reply with the JSON payload as a response.
Postman Testing
Executing the integration with status TRACE, I can view the mapping payload. This is the mapped payload that was used for the API call to S/4HC.
Mapping Result
The project in S/4HC and it is ready to be used with the correct structure.
New Project in S/4HC
Now that we have a working REST API on BTP Cloud Integration, we are ready to start building the low code app using SAP Build tools. I'll cover this process in the next two blogs.
Thanks,
Marty
4 Comments
