<p>about your learning experience to help us improve.</p>

You've completed

cleanFiles/bookmap_SAP_Order_Management_-_Technical_Baseline_en-US_learning-sap-com_lsc-prod.zip (MMCP-DROPZONE) - 2024-12-17T10:36:30.000Z

Setting up iFLow & Configuration

<div id="content"><div class="parentsection"><div class="section"><div class="kalturaVideoLessonWrapper"><div aria-label="" class="kalturaVideoLessonContainer" data-testid="video" id="1_r6dc70at"></div></div></div></div><div class="parentsection"><div class="section"><div tabindex="0"><h3>Configuring iFlows</h3></div><p tabindex="0">Detailed instructions are provided on configuring iFlows using the API hub. The process involves copying artifacts, configuring connections, and utilizing security materials for seamless integration with SAP S/4HANA and data ingestion.</p><div class="note"><div class="noteTitle"><span class="noteIcon"><img title="Note" src="/icons/note.svg"></span><span class="noteTitleText">Note</span></div><div class="noteBody"><p tabindex="0"><strong>Prerequisite</strong>: Establish connection to API Hub.</p></div></div><p tabindex="0">Go to discover in your Cloud Integration and look for the Data Ingestion Integration Package.</p><p tabindex="0">Search for the integration package on API Hub.</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Screenshot of SAP Cloud Integration interface showing the search bar and a list of four integration packages related to SAP S/4HANA." alt="Screenshot of SAP Cloud Integration interface showing the search bar and a list of four integration packages related to SAP S/4HANA." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_002.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Once the package is opened, click on copy to take it over into your cloud integration instance.</p><p tabindex="0">Make the package available.</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Overview of Data Ingestion for Industry Cloud Solutions Integration with SAP S/4HANA, detailing data mapping and integration capabilities." alt="Overview of Data Ingestion for Industry Cloud Solutions Integration with SAP S/4HANA, detailing data mapping and integration capabilities." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_003.png" tabindex="0"><div class="imageCaption"></div><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Overview of the SAP Cloud Integration package for data ingestion between SAP S/4HANA and Industry Cloud Solutions." alt="Overview of the SAP Cloud Integration package for data ingestion between SAP S/4HANA and Industry Cloud Solutions." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_004.png" tabindex="0"><div class="imageCaption"></div></div></div><div class="parentsection"><div class="section"><div tabindex="0"><h3>Configure and Deploy Artefacts</h3></div><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Screenshot showing SAP Cloud Integration setup for OAuth2 Client Credentials with relevant fields and deployment status." alt="Screenshot showing SAP Cloud Integration setup for OAuth2 Client Credentials with relevant fields and deployment status." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_005.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">For each entity (replication object), there are 3 artifacts</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Screenshot of SAP Data Integration platform showing various artifacts related to plant mapping and customization for data ingestion." alt="Screenshot of SAP Data Integration platform showing various artifacts related to plant mapping and customization for data ingestion." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_006.png" tabindex="0"><div class="imageCaption"></div><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Table showing groovy scripts in a collection: get_row_count, log_exception, and log_payload with brief descriptions for each." alt="Table showing groovy scripts in a collection: get_row_count, log_exception, and log_payload with brief descriptions for each." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_007.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Activate the Retry iflow to handle replication errors due to timeouts</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="" alt="" src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_008.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Typical <i>iflow</i></p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Flowchart illustrating the integration process for replicating a plant from SAP S/4HANA, including error handling steps." alt="Flowchart illustrating the integration process for replicating a plant from SAP S/4HANA, including error handling steps." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_009.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Configure the <i>iflow</i> (Sender)</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Configuration interface for replicating a plant in SAP S/4HANA, showing sender, connection settings, and endpoint details." alt="Configuration interface for replicating a plant in SAP S/4HANA, showing sender, connection settings, and endpoint details." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_010.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Configure the <i>iflow</i> (More)</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Configuration options for Replicate Plant from SAP S/4HANA, displaying parameters like credential name and data ingestion address." alt="Configuration options for Replicate Plant from SAP S/4HANA, displaying parameters like credential name and data ingestion address." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_011.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Adjust <i>iflow</i> with custom mapping</p><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Interface showing message mapping for plant data integration, with a detailed structure for JSON schemas on both sides." alt="Interface showing message mapping for plant data integration, with a detailed structure for JSON schemas on both sides." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_012.png" tabindex="0"><div class="imageCaption"></div></div></div><div class="parentsection"><div class="section"><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="JSON data snippet showing distribution center details, including ID, name, and address, along with object name and datasource information." alt="JSON data snippet showing distribution center details, including ID, name, and address, along with object name and datasource information." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U2_L3_T1_013.png" tabindex="0"><div class="imageCaption"></div><ul style="list-style-type:disc"><li tabindex="0">Call <i>API</i> endpoint of <i>open api</i></li><li tabindex="0">Use <i>suffix</i> as per the default endpoint name e.g.</li><li tabindex="0">/central/v1/sap/plants/replication</li><li tabindex="0">Use <i>oauth</i> credentials from Data Ingestion Instance</li><li tabindex="0">Build Payload for example</li><li tabindex="0">Use mandatory header parameters</li></ul></div></div></div>

Setup & Configuration

Customizing technical baseline of SAP OMF and SAP OMSA

<div>Discover how to implement and deploy iflows for data ingestion and integration with S4HANA. Learn about standard integration packages, API references, schema definitions, and configuration steps.<br><br># This description was auto-generated #</div>

Showing how to Setup the Required iFlows on Cloud Integration

Now let's look at the ifloway, what it takes to implement the iflows and deploy the iflows. Right, so what we want to understand is where we find the standard integration package and of course there's one entry point is the API hub. So if we go here to, let me do this, if we go here and say API subcom, and we say here data ingestion, for example, then we see here that we have an API package for data ingestion for industrial solutions. So if we go there, we see here in this api.sub.com, so everybody, I guess, has access to that. And here, you see these different entities, right? So we saw earlier that we have, for example, the ATP snapshot that is required for OMSA. And if you go here, you see, I think that's what Paula already has shown, that you can download here the JSON schema, YAML files for that. You can go here. That's what I typically use, is that you have here this API reference. And you can see here in schema what the interface pretty much looks like. So you have here the value. You see here that you have a product aspect with an ID and so forth. Of course, you have a plant. And you have here your availability quantities, right? So here you can have a look what the data type looks like. I said you can download the schema definition. But here this already gives a quite good glimpse, maybe sometimes what is expected. So if we have somewhere like a code list or something, then you can have a look what values would be accepted there. right. So this is where you would go to. And this RP package here, these are the APIs of data ingestion. And if you connect from your, let's go back to the slides, if you need to establish in your BTP a connection to the API hub. And if that's done from cloud integration, you can go to this discover part here and you can search with ingestion and see all the iFLO packages that are available. So here we know that we are looking for the data ingestion for industry cloud solution integration with S4HANA. Then we go to this discover, we find it here, we click on it, and then we see here that there are, this is August 23 when I did the screenshot, we have here 170 artifacts. An artifact can be anything that is used in cloud integration for the iflows and what it needs. So it could be like a script collection, what we will see, it could be an iflow, it could be something else. Everything that we need to connect as for and do a mapping to data ingestion. I mean here in data ingestion out of the box we don't really need a mapping because data ingestion pretty much already sends the data out in a JSON way. So if we say that for certain entities we don't need any adjustment The iflow is pretty much a throw-through of a message coming in and exactly the same message going out to data ingestion. We would see later what we can do if we don't, if we're not happy with that, because we want to have something else. Right, but here we see that we have these artifacts. 170, we will see what is in that package in a minute, but if you say copy, then you move it from pretty much rphub to your cloud integration account. And then you have it available locally or in your account. You can configure it. We will see how that works and you can use it. And then, I mean, even if you say the copy doesn't mean you don't copy the package, it's still standard. And there is a definition, because you might know that if you have cloud integration and you are just using SAP to SAP communication with standard iflows, of course, you have to pay, or your customer has to pay for cloud integration with a fixed price. But there's also some quota or some metrics that are defined by volume. So the customer would say, I license cloud integration with 3 million messages. As long as you communicate from SAP to SAP without modifying the I-flow, just configuring it. And this is also the term that is used. I think I shared the OSS note on Tuesday where you can get all the definition of what is quota relevant and not for cloud integration. But if you'd only take this standard iflow, you copy it to your own instance and you configure it. There's no additional cost. If you start copying it into your namespace, so say I don't take the, just this copy, just take it over and configure it, but I change it and I rename it. and whatever it then it becomes a custom iflow and then it's quota relevant but as long as you just configure it and then it stays a standard and you can still use it. Right so here we copied it over now into our local into our account and then we move from this discover to this edit tile here in cloud integration. And now we can have a look at the iFlow. Once again, we need our service key to be able to connect to data ingestion. So in cloud integration, we have here in this bucket here, we have something called security materials. And in the security materials, you you can do something similar that we have done in S4, create like an OAuth profile. Here in the security material, you can say I create a new value. And here I create my OAuth profile, again, with this client ID, client secret, with my URL, how to get the token. And then I name the security material IRMDI, for example. So you don't have to configure in each iflow the OAuth credentials. You do it once in Cloud Integration, the security material. And then when you configure an iFlow, then you take this security material name in the configuration. So you don't have to put any credentials inside of the iFlow. For each entity that we have, so we said an entity is a plant, is a product, is a product plant, is an ATP snapshot. we have three artifacts in that picture. One, this mapping is for mapping, but only if you need adjustments. Like I just said, for data adjustment, at least it's a flow through. So if you don't have requirements to change something in the mapping, you can just, yeah, you can just, you basically don't need this mapping. And the customization iflow, this is a sub-process in the iflow that would call this own mapping. And this is the main thing here, the replication product planned from S4. This is the iflow. You always need to deploy all three of them. Otherwise, the iflow would not be completely defined. And also, once at least for all, there are some things that have to be activated as because they are used in all iflows and here this is a groovy script package. So you might know if you have worked with cloud integration or you know, cloud integration, that anything that you need to like program in form of process orchestration or process integration, whenever you used it and the name was at that time. And you had something that you would do with XSRT, where you would do some sort of programming and, or you had little JavaScript things that you could use in functions in CPI now in cloud integration, that's new name cloud integration and you would, can use something natively that's called Ruby scripts that you can use as little functions in your mapping, for example, or even replacing mappings where you would code what the result needs to be or how do you influence this? For example, there's a Ruby script here that would calculate a row count. We need this in API management. We need to tell cloud integration that we are just sending over in this package, 100 articles. So this groovy script here calculates that the package contains 100 articles, for example. Or the log payload is a little script that would persist the payload of the iflow into the iflow. If you go to monitoring cloud integration, you can then directly access the payload, which is quite useful and quite handy. Right. So this is something that you have to deploy to make it available. So, everything that you want to run and that you need in your usage, you deploy it, right? And then you have it available. So this common functions is something that you need to activate it because this is required by all the iflows. And there's also one retry iflow. So if a message cannot be delivered, because for whatever reason, data ingestion currently has a maintenance window, then you can activate the sub-iflow and this would take care of resending the message via jmsq. Right, so a typical iflow, here it's the replicate plant, is that we see later in configuration that we can set certain values to true or false. So what happens here is that we receive data from S4 in a certain kind of way. We have here a first choice if we want to use the customized mapping or not. If not, the message just flows through here. Then the next question is, do we want to log the payload? Meaning we want to see monitoring for every run through that we see the payload and that we have it directly accessible. You might know, for those who have worked with cloud integration, that you can set something like a trace level. So if you say, ah, we have an issue currently with our iFlow that we have built on our own, but to be able to see what happens, we need be able to see the payload that arrived and see why what is strange. There was a bug some time ago that we sent from S4 timestamp. The shop has opened from 0 o'clock to 24 o'clock and the iFlow pales and we first of all we didn't know what the reason was and then after activating the trace, but this trace is only always available for 10 minutes. We were able to see that there was a regex validation that said the time has to be at maximum time allowed is 23 59 59. So it didn't accept the 24 o'clock what we allow in S4. Of course this was corrected long time ago, But this trace capability allowed us to see what data came in and to see more details on the error. If you want to say we do now a test, we cannot really tell randomly some messages fail. You can set this, deploy this iflow in a kind of way that it locks this payload and that you see this payload for a longer period. Of course, you shouldn't use this in productive usage and always keep it on, because then of course the data would pile up. I think there's a certain retention period, but this would for every message that you get would persist the payload in the iflow, which doesn't make sense in a normal productive usage. Right. So here you can deploy this iflow with this option turned to true. Then it will lock the payload or to false. Then it will not block the payload. Right. And then this information would then be sent to data ingestion. If something happens, then here's this exception handling part. And we have this error retry here below. Right. So this is pretty much what all the iflows that are used from S4 to data ingestion look like. So you can just go the run through way, or you can replace the mapping. And here in the configuring part, this is something that you would really have to do for each iflow. For example, in sender, you say, OK, my sender is my S4 system. This is just the, it doesn't have to be some specific name for the customer. It's just S4. adapter type with HTTPS, that's pretty normal, and here in this s address you would set this endpoint name here. So this is what I showed earlier, we have this default endpoint table and here in this iflow when we deploy it we use this path here so that the one HTTP destination that we have defined in S4 together with this endpoint path would exactly address this iflow. Then we have here after sender we have a tile more and here we maintain the credentials that we have created. So our profile that is in SM59 or in the RFC connection is here then in this credential name. So we don't have any client ID secret in this iflow, sorry. We have here this credential name, which is part of the security materials cloud integration. We maintain the data ingestion host address here. This is again from this, you see this in the service key from data ingestion. This is the data source. If we send it directly to API management, this is the business system name that we get through this function module. This is sent directly. If we send it via the iFlow, we have, we choose here the right name. And this has to match the name that we defined a data ingestion in the app at the beginning, right? There we said, we have a source system. This is what the source system is called. This has to be this value, right? So otherwise it would fail. Um, and that's why I said we recommend to use this name that would be sent also on the direct way. If you, for some reason already one year back, define the different name. and define a different name and we cannot change it anymore. And then in the iflow, you could configure a different name, right? Then you can say, okay, I put here the value that I defined once in data ingestion. So that's why here it could deviate from what the system says, what the system name is, right? So you can figure it out here. And here, these are the two settings that are set. So enable log payload is set to false, enable mapping is set to false. If you want to temporarily have all the logs, you can set it to true. And if you need a different mapping for an entity, you want to change the mapping, then you could set this enable mapping to true and then this custom part would be called. Right. Yeah and if we want to adjust the iflow there is one template mapping delivered. This is pretty much a one-to-one mapping from this JSON file already coming in in the correct format and the JSON file that goes out already in the correct format and here is a simple one-to-one. So it's out of the box, it's a flow-through, that's why we don't even need this mapping if it's not required. But for example, at one customer, they said S4 system delivers me the ESO unit. But for whatever reason, I need the SAP unit instead of the ESO unit to be put to data ingestion. Of course, you have to always be careful what you manipulate, because others might need it in a different form. But if you have a requirement like this, where you say I need to some manipulate name maybe or whatever. You could do this via this iflow and then overwrite the flow through with a custom mapping here. That is the iflow communication. I see a question here, should we perform any additional steps if our S4 system is on-prem private cloud? No. No, I mean this configuration that I just showed you for S4 on-prem private cloud or public cloud nevertheless is all the same. The only thing that you need to have in mind is that an S4, this OAuth button or transaction that I showed you is delivered I think with S4 2021 if I'm not mistaken or 2022. So in 2020, there's a certain customizing that you have to use for this OAuth. And you might switch then to basic authentication instead of OAuth for addressing UI flow. But that's the only difference that I'm aware of. Data ingestion, that's also important. is not down ported to ECC. So the DRF that feeds data ingestion was specifically developed in S4 and was not downgraded to ECC. This is something that you have to be aware of in your customer projects that you cannot use out of the box at least data ingestion with ECC. You would have to somehow map an art mass to data ingestion or whatever. But the pure DRF thing that was delivered is not available for ACC. Right, so I hope, yeah, thank you. That's a good question, very good. All right, yeah, so if we want to send data from a different system to data ingestion, so not from S4, then we can directly, or for purposes where we want to create data and data ingestion with Postman for testing, for example, or if you want to simulate an integration, we can do so. For example, with Postman or any other REST tool, we have to take the endpoint. We take the suffix. So the suffix, for example, for replication of plants, we use the OAuth credentials from data ingestion. So exactly the same thing, client ID, client secret, and OAuth token as address. We get our token and we send it with a request. We have to build the payload. So in API Hub, what I showed earlier, you see examples. You see what the structure needs to look like. You can download the JSON schema. And this is the payload that you have to build. So for example, here, this is the beginning of the plant payload. So some ID, some name, some address, some time zone, whatever, right? And then you can send it. What is important is that you need to send these three header parameters with the request that you send to data ingestion. So you need to reference here, even if it's here in the path, but you need to reference the object name. You need to tell what data source. This is again, the data source that you configured in data ingestion. And you need to send over the row count, right? To say here, I'm sending you three plants or I'm sending you one plant. Right, and this is all it takes basically to send data to data ingestion from a different source or from Postman, what we use a lot when testing with customers, some OMSA features that we quickly want to upload certain stock levels or whatever to be able to simulate certain stuff. Then we do it with Postman and exactly that way. Henrik, what do you think about a break? Yeah, this is just a link as a data ingestion administration guide where you can get all the details, but sometimes it's easier to see it with screenshots.