<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 technical Prerequisites

<div id="content"><div class="parentsection"><div class="section"><div class="kalturaVideoLessonWrapper"><div aria-label="" class="kalturaVideoLessonContainer" data-testid="video" id="1_715pgyi7"></div></div></div></div><div class="parentsection"><div class="section"><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Graphic showcasing SAP features, including data replication, integration options, and system configurations, with two computer screens displayed." alt="Graphic showcasing SAP features, including data replication, integration options, and system configurations, with two computer screens displayed." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U3_L1_T1_001.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="Diagram illustrating the data flow from non-SAP solutions through APIs to data ingestion, quality, persistence, and monitoring processes." alt="Diagram illustrating the data flow from non-SAP solutions through APIs to data ingestion, quality, persistence, and monitoring processes." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U3_L1_T1_002.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">This schema shows the processing flow in greated detail. Data Ingestion manages the persistence and data consistency from the import of data through the Open APIs, through Kafka processing and persistence in a data lake. From there the industry cloud solutions fetch the relevant data.</p><ol><li tabindex="0">SAP Data Ingress - <code>DRF</code></li><li tabindex="0">Non-SAP Data Ingress - <code>OPENAPI</code></li><li tabindex="0">Source Authentication</li><li tabindex="0">Data Quality Validation</li><li tabindex="0">Data Encryption</li><li tabindex="0">Data Persistency (Lake)</li><li tabindex="0">Controlled Data Access</li><li tabindex="0">Integration Monitoring</li></ol></div></div><div class="parentsection"><div class="section"><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="Diagram illustrating integration flow between S/4 S21, Cloud Integration, and CIC BTP with various replication models and subaccounts." alt="Diagram illustrating integration flow between S/4 S21, Cloud Integration, and CIC BTP with various replication models and subaccounts." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U3_L1_T1_003.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">Communication paths from <code>DRF</code> to Cloud</p></div></div><div class="parentsection"><div class="section"><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="SAML configuration screen showing connection settings, HTTP proxy options, and general service provider details." alt="SAML configuration screen showing connection settings, HTTP proxy options, and general service provider details." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U3_L1_T1_004.png" tabindex="0"><div class="imageCaption"></div><div class="note hint"><div class="noteTitle hintTitle"><span class="noteIcon hintIcon"><img title="Hint" src="/icons/hint.svg"></span><span class="noteTitleText">Hint</span></div><div class="noteBody"><p tabindex="0">See Unit 2 Lesson 2 (identical setup)</p></div></div></div></div><div class="parentsection"><div class="section"><img style="max-width:900px;max-height:none" class="image 1_1_landscape" title="SAP Display IMG interface showing settings for business systems, including logical paths and replication options." alt="SAP Display IMG interface showing settings for business systems, including logical paths and replication options." src="/service/media/ICOMF4_02_en-US_media/ICOMF4_02_en-US_images/ICOMF4_U3_L1_T1_005.png" tabindex="0"><div class="imageCaption"></div><p tabindex="0">In Transaction <code>DRFIMG</code></p></div></div></div>

Prerequisites

Customizing technical baseline of SAP OMF and SAP OMSA

<div>Learn about the data replication framework and how it works across different systems and cloud integrations. Discover key insights on implementing and optimizing the data transfer process.<br><br># This description was auto-generated #</div>

Explaining how to Setup the Technical Prerequisites like RFC Destination, oAuth Configuration, and Business System Definition

In the data replication framework, how to send this stuff over. One thing that is important, some of you that have worked specifically with CAR, for example, or mainly know this data replication framework. The data replication framework is something that is not really retail specific. and generic framework that sits in S4 and was already available in ECC but has certain flavors. So the framework pretty much defines certain interfaces and each object that will be sent with the DRF has to implement these interfaces and then you can transfer data. So even if you would say in your project we have all created own set tables and own objects. We want to send them over with DRF. You could implement those interfaces and create your own DRF object. But for industry cloud, like I said, they defined that we need something central to send out data. the data replication framework works in this scenario is established so customers is available so they didn't have to reinvent everything so they've leveraged that but they made some changes not to the framework that's important just the implementation of the framework, there are some stuff that is specific to cloud integration. That's why also the DRF object that we have sent to CAR as product is a different object than the industry cloud product that we send to cloud integration or to data ingestion, sorry. Right, so it's based on the sub-data application framework. It is optimized for industry cloud solution. There is some change in how filters are handled. We come to that. There's a specific chapter on that. As an output, a data DRF or the objects will send out directly the JSON that data ingestion needs. So we don't send some item type or RFC or whatever, if format out the data replication member for industry cloud already produces a JSON according to this ODM model and sends this out. So yeah, as an extensibility thing, right now, as I said, data ingestion itself does not yet have a productive extensibility concept, but that's on the roadmap. So that you can say we need five fields more on the article. That right now is not possible. So you cannot add five attributes to an article. But, and that's something we already did for projects, if we need to, for example, in one project, they said we have our own logic, how the short text needs to look like. So we cannot just check the short text from the article. We need to have it a little bit longer, maybe, and with some different elements, right? So we, we, we compose our text for that application and for industry cloud. We need to rephrase or send the text in a kindly different moment. So this is already possible. Right now, we will get options on doing that without enhancement and modification. As of now, little enhancements are required, but it's possible. And this is something that is also on the roadmap. I can, I cannot give you a date for that. Um, but there's something that, uh, we will get to be able without modification to change the content of the message. Like I said earlier, if you would have everything already in the iFlow, you would be able to use the customization in the iFlow to maybe change what is sent over in a certain field. But, yeah, if you need something that, for example, you want to change the short text, right now you would have to do it with little enhancements. So extensibility in DRF, yeah, right now with restrictions, but I think we hopefully soon get a possibility to do a little bit more. Right, so like I said, the message is sent out already in JSON format, so if we want to manipulate what we sent out, we can manipulate the content of the JSON. Right now, like I said, only with enhancements, but I hope that will change. The simplified RFC connection setup, we already discussed, we don't need a destination for each object. We have this one connection for iflow or this one connection for direct connection and the suffix is coming from this default endpoint or custom endpoint table. Right. So this is about... Hendrik, I think we have one raised hand. Should we respond to the question or shall we we postpone? It's just a question if we get access to the slides, right? Sorry. Or do you see something else? I've seen a raised hand. OK. Sure. So can you please pick up who raised the hand? No, it was maybe, maybe I would assume it was an accident. Okay, I don't know, maybe you can ask the question in the F&A and we can pick it up. Yeah. Um, yes, so, uh, this is basically what I had to say, the data replication framework in which sense it's maybe different than you would know it. It's a different object for sure. And um, yeah, so we had this slide here already. We sent out S4, we sent out the DRF message already in this one domain model. We have the monitoring and observability with Calm, what I just showed. And we have, again, our communication path, so either via direct or via business system. Why is that important? We have to set up now the connection and replication model so that we can send out this data here in these two to this two destinations or one destination, whatever you choose. Right, so the RFC destination and the OAuth configuration is pretty much the same like we already said. So we already configured here the OAuth profile, we already configured the RFC destination for aiming our iFLOW, for aiming our direct connection. So that doesn't change, it's exactly the same, we still need that. Then in transaction DRF-IMG we have everything together pretty much that we need for this data replication framework configuration setup. We set here a technique consisting for a business system. If you create an entry here, right, because here is our RFC destination, here for direct connection, or we have another one for the iflows, and we type here a business system. This business system, of course, does not exist in an SLD because it's not really one system. We want to send it to cloud, to data ingestion, so the data ingestion is not connected to our system landscape directory. So we just type in here a name that makes sense. If you enter this it would raise a warning that this message or this business system is not configured in SLD but it's just a warning you can just ignore that. We know that it's not connected to SLD and that's fine. So we type here name, we map our RFC destination that we have created and then we're good to go. So here is another view of the objects that we need. So I showed a different page earlier. This one here, this overview and the list is here linked, is that here we see, for example, if you look for plant, we see the entity name, right? So we saw this in data ingestion that is used. We see the business object type, which is configured in S4. And we see the outbound implementation name that is also configured in S4. So that's quite important because then you cannot go wrong. So if you get here all the names, sometimes based on DRF, either the business object or the up on implementation that is used. And if you're looking for the right airflow, it's more the entity that you look for. So this is quite helpful here, this list. And you also can see here then quicker what to configure. Right. Then we have here, like I said, we have our defined technical system business system, and then we maintain replication model. So here we have our application. So we have a replication model that I named here data ingestion all. Of course, once we at the end, have to activate it so that it works right and that we can send data over. And yeah so I define this name here and then I assign out. So I choose the upload implementations that I want to use. It's important that we only choose the upload implementations that we really want to use because once we activate it it, for some it might already change right, start changing, writing change pointers. So we should only choose the above implementations that we really want to activate and send out. So, and by the way, these entries here, it's sometimes a little bit misleading. It looks like F4 helps and you but you kind of really change that. So it's not really an option to change it here, it's like delivered for this up volume mutation. Right, then we choose target system. Normally, if you say I said we said directly or we sent via iFlow, you would maybe only have one target system. Here in our list system, we have two because, like I explained, we have this direct and the iFlow way. Yeah, that's, that's why we have two here. But Normally you would have only one, basically. Right, then we assign this target system. Here, this information in this view here is just to tell you what elements or what objects would support, there's a new change pointer, this so-called MDG change pointers. And this view here that you shouldn't change, of course, would tell you what elements support these new change pointers. So this is just for information purposes. And one thing that is very important and critical is that there is here in this defined business system, you have to scroll to the right and you see if you should make an entry here, this table here is delivered empty. For each business object type, and now we saw the business object type in this help side that I've shown earlier. If you don't set anything, the default might sometimes be direct output. So as soon as you, for example, activate replication model and you activate the change point and so forth, data might be sent out directly. And typically, at least for mass objects, you don't want that, right? We want to have change pointers. We want to send a job that runs every two hours, once a day, whatever. But then the change pointers should be pooled and then sent out in a bulk, right? Rather than shooting every message directly individually. So it is important, what we recommend customers is pretty much enter all business object types here and set them to pooled. Maybe you don't need that for some simple customizing sales organization, replication, whatever, right? There, you might not even go via change pointer, but yeah, for mass data, you should absolutely to use this pooled output here.