It defines the unique URL used when the iFlow is deployed on BTP, in such a way that a Sender knows what to call:
The /salesorder/detailsv3 is appended to the URL created by CPI when it successfully deploys and starts the iFlow. This full address can be found in CPI Edit mode of the iFlow - click anywhere in the screen to see the following
Block 3. Content Modifier
This stores the incoming payload in a variable property.textToChatGPT so that it can be used in subsequent iFlow steps. In the current version of this iFlow this step can be left out - as I used the property in earlier versions for calling ChatGPT. I leave it in here to show a best practice in keeping the initial payload for reference sake in subsequent iFlow steps.
Block 4. Groovy Script
It takes the input ("payload") entering the iFlow and parses the text to search for an integer (of a certain minimum number of digits) which is written after the word SalesOrder. The search result is written in property.ExtractSuccess - where 1 is successful and 0 unsuccessful. An integer number found is stored in property.extracted_integer which is used in the API call to S4HC Public.
Note: initially I wanted to use ChatGPT API to parse the text and return the SalesOrder number. This works perfect in the ChatGPT UI but unfortunately is not working consistently in the API. Many hits on the web show that this behaviour is experienced by others often too like this source: : https://community.openai.com/t/different-results-chatgpt3-5-vs-api-gpt-3-5-turbo/123712
Block 5. Router
Based on the ExtractSuccess value the route is determined, with the default route being the main line in the iFlow. In case ExtractSuccess = 0 then the Route2 is taken which will lead to sending a failure email and stopping the iFlow.
Block 6. Route 2
This will make the iFlow not to take integration steps but instead jump to replying the customer with an email.
Block 7. Content Modifier
This sets an explanatory text which is used in the email reply being sent. An improvement can be to use the name of the initial sender of the incoming iFlow payload , instead of using the generic "Dear Customer".
Block 8. Message Flow
This message flow is of type "Mail". It defines the details for sending an email. The General tab in this iFlow component allows giving it a name and description. In the Processing Tab the email To: and From: addresses are specified. I use hard coded these in this iFlow, but for obvious reasons these should be changed by using property variables. The same could be done with the e-mail Title.
The Connection Tab is used to define the SMTP details which are used (or enforced) by the email system to send out the email. The authentication in this case is User/PWD combination defined at the email system.
The values of the UserID and Password are stored in a credential name - which you create/store in the Security Material tile of CPI
Block 10. Request Reply
This CPI component enables an external call to be made and a reply being received for further processing in the integration flow. Here we perform the API call to SAP S/4HANA Cloud, Public Edition. The API called is a "whitelisted" API which can be activated by setting up a so called "Communication Arrangement" in S4HC - which makes the API available with the desired credentials and access. These credentials are stored in the Keystore just like other credentials.
The Request Reply defines what the URL of the API is, what authentication to use and how its credentials are found. In this iFlow experiment I used basic UserID/Pwd credentials on the API - but for obvious reasons in "real life" cases a stricter policy such as OAuth2.0 should be used. The UserID/Pwd credentials are storied in CPI in the "Credential Name" tag.
The Processing tab defines what the API call is supposed to execute. Here, I perform a GET operation to read a certain amount of fields which are available with the API - in this case I pull only a handful of the 40+ fields this API has to offer. In order to prevent getting back far too many data I let the API filter on the earlier filled "extracted_integer".
CPI helps you in selecting those XML tags nicely - as you can choose which part of the XML reply from S4HC you are interested in (here - I select A_SalesOrder), then to select the specific tags and finally set up your filter/sort:
When multiple APIs in your S4HC Public Edition system are available, it is pretty easy to toggle to these and select data too.
Block 11. Groovy Script
With the XML based reply received back from S4HC one cannot work directly in an API call to ChatGPT. Therefore I created a groovy script which executes several steps:
Making this groovy scripted was very much helped by using SAP Digital Assistant - which is a GPT4 based tool and a real powerhouse helping you creating and improving groovy scripts - and tons of other things!
it is in groovy script that the "ChatGPT magic" happens in terms of how a reply must be made - I am sure there are better ways, but as I am a rookie in ChatGPT too this is the best I could make given the time I had given myself for my challenge:
I must admit that does look a bit groovy and spooky, ay?
Block 12. Request Reply
Here, I execute the HTTPS call to ChatGPT API. As the message and details were set in my groovy script in Block 11, the HTTP definitions are all it takes to get a response from ChatGPT.
Block 13. JSOn to XML Converter
I have been toggling with this step a bit - as it seems not to do much:
But If did not convert the JSON reply from ChatGPT API into XML he last step 14 would gave challenges in properly parsing text. It was here where SAP Digital Assistant gave me good guidance too!
Block 14. Groovy Script
This step executes a the parsing of the incoming XML from step 13 and this script then prepares a readable body text which is used in step 15.
Block 15. Message Flow
This one has exactly the same content as the one in Block8.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
7 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
2 | |
2 | |
2 |