In the previous post, we explored the business requirements and the integration setup between the source system and the cloud integration. In SAP CPI Project IFlow Walkthrough 2 – Replicate Sales Pricing Condition Records from ECC to S4HANA, we will delve into how this process is implemented in the Cloud Integration system.
Overview of this blog series:
1. SAP CPI Introduction
2. SAP BTP tools and features overview (BTP, Global Account, Sub-Account, Entitlements, Connectivity, Security)
3. SAP CPI Web IDE overview
4. Registering a trial account and enrolling to SAP CPI service
5. Deep dive into Cloud Integration features with real world scenario example
6. Use cases of palette functions
7. Adapter configurations
8. Using Cloud connector for connecting to backend SAP systems
9. Overview on API Management & Open Connectors
10. Integration using Open Connectors with real world example
In short, below is the content we will elaborate in this tutorial:
1. Understanding the Pricing condition IDOC Structure
2. Pricing condition API – API_SLSPRICINGCONDITIONRECORD_SRV
3. IFlow development
Understanding the Pricing Condition IDOC Structure
Pricing Condition IDOC –
Basic type – COND_A02
Message type – COND_A
The schema XSD file can be downloaded from WE60 Tcode.
In the basic type enter – COND_A02 and select Documentation menu option -> XML Schema.
Right click and save it as XSD.
Concerning construction of the Estimating condition IDOC, there are 4 principal hubs: Underneath model is according to our utilization case and could change contingent on the table you are sending.
E1KOMG (contains the header subtleties: cost list type, condition, condition table, condition type, material. Event is 1)
—–E1KONH (contains condition record number, validity start date, validity end date. Occurrence is n times)
———–E1KONP (contains the price details)
—————-E1KONM (contains the scales information. Scale quantity and scales amount)
Sample payload:
<COND_A02>
<IDOC BEGIN="1">
<EDI_DC40 SEGMENT="1">
---------
</EDI_DC40>
<E1KOMG SEGMENT="1">
<KVEWE>A</KVEWE>
<KOTABNR>728</KOTABNR>
<KAPPL>V</KAPPL>
<KSCHL>XX00</KSCHL>
<VAKEY>I1000003058109001000</VAKEY>
<PLTYP>KF</PLTYP>
<MATNR>000000002500100981</MATNR>
<EVRTP>00000</EVRTP>
<POSNR>000000</POSNR>
<ANZSN>0000000000</ANZSN>
<VAKEY_LONG>I1000003058109001000</VAKEY_LONG>
<E1KONH SEGMENT="1">
<KNUMH>0068243508</KNUMH>
<DATAB>20200101</DATAB>
<DATBI>99991231</DATBI>
<E1KONP SEGMENT="1">
<KSCHL>XX00</KSCHL>
<STFKZ>A</STFKZ>
<KSTBM>0.000</KSTBM>
<KSTBW>0.00</KSTBW>
<KRECH>C</KRECH>
<KBETR>60.00</KBETR>
<KONWA>EUR</KONWA>
<KPEIN>1</KPEIN>
<KMEIN>PCE</KMEIN>
<KUMZA>0</KUMZA>
<KUMNE>0</KUMNE>
<MXWRT>0.00</MXWRT>
<GKWRT>0.00</GKWRT>
<ZAEHK_IND>01</ZAEHK_IND>
<KBRUE>0.00</KBRUE>
<VALTG>00</VALTG>
<VALDT>00000000</VALDT>
<ANZAUF>00</ANZAUF>
<MIKBAS>0.000</MIKBAS>
<MXKBAS>0.000</MXKBAS>
<KOMXWRT>0.00</KOMXWRT>
<KLF_STG>0000</KLF_STG>
<KLF_KAL>0000</KLF_KAL>
<E1KONM SEGMENT="1">
<KSTBM>2</KSTBM>
<KBETR>60</KBETR>
</E1KONM>
</E1KONP>
</E1KONH>
</E1KOMG>
</IDOC>
</COND_A02>
Whenever there are various records for a material, there will be different E1KONH sections in the source IDOC.
2. Pricing Condition API – API_SLSPRICINGCONDITIONRECORD_SRV
Buyers of this inbound assistance can make, read, update, and erase condition records inside your framework by utilizing OData demands. The assistance contains substances for condition record, legitimacy of condition record, estimating scale, and condition supplement. This is a standard OData Programming interface administration given by SAP.
In SAP Business Gas pedal Center, you can find the Valuing condition record OData Programming interface for S4HANA.
In the Programming interface reference, you will actually want to see the potential elements accessible and the tasks accessible for the equivalent. It’s an OData V2 administration.
3. IFlow Development
We should begin with how I fostered the connection point for repeating the estimating records from ECC to S4HANA.
We should take a gander at the initial not many strides, as displayed in the underneath picture:
- Initial step is getting the IDOC payload from ECC framework. The availability part is as of now talked about in the past post.
- Next 2 stages can be overlooked. It is for client assurance.
- Prior to continuing with the business rationale, we should store the source payload. I have done it through sweet.
import com.sap.gateway.ip.core.customdev.util.Message;import java.util.HashMap;
def Message logInput(Message message)
{
def body = message.getBody(java.lang.String) as String;
def messageLog = messageLogFactory.getMessageLog(message);
if(messageLog != null)
{
messageLog.setStringProperty("log2","Printing Payload As Attachment")
messageLog.addAttachmentAsString("IDOCPayload",body,"text/plain");
}
return message;
}
In the subsequent stage, you can see we have utilized OData call (custom) to get the comparing unit of estimation in S4 for the ISO got from ECC. To pass the ECC ISO code, we are putting away the ISO UOM in the past satisfied modifier. The config in ECC is kept up with so that, the ISO UOM code is shipped off CI, however when we straightforwardly pass it to S4 through Programming interface, we were getting a blunder as “Unit PCE not characterized in language EN”. After exploring on this, we found that the ISO change need to occur prior to passing the worth to S4 Programming interface.
- In the next content modifier, we will be storing the S4 UOM in the property.
In the following two or three stages, we will be parting the IDOCs and steering it to Make/Update activity.
- As we will get different condition records in single exchange, we really want to part it into individual records. Thus, we utilize General Splitter.
XPath – /COND_A02/IDOC/E1KOMG/E1KONH
The split condition records are passed to message planning. In this message planning, we complete 2 changes.
a. Date conversion: ECC date sent – yyyymmdd
S4 accepted date format – yyyy-mm-ddThh:mm:ss
b. Material code conversion: ECC format – 000000002500100981
S4 accepted format – 18 digits – 0000002500-100-981
The S4 acknowledged individual condition records are passed to the subsequent stage, where we will store the important qualities in the substance modifier. These will be required when we need to decide if it needs to go to make or refresh branch and furthermore in a few different cases.
- In the following stage, switch is utilized to check in the event that the condition table field is equivalent to 628/756. Rest of the tables, we are simply passing to make activity. No update will occur for different tables.
${property.ECCConditionTable} = ‘728’ or ${property.ECCConditionTable} = ‘656’
- Presently to check assuming the record exists in the S4 framework, we would do an OData call to the evaluating legitimacy substance by passing the material, legitimacy start date, legitimacy end date, cost list type that we get in the source IDOC. You can overlook the past awesome step, where we outline the OData channel question for various tables and pass the channel boundary in the OData settings step, similar to this – &$filter=${property.filterquery}.
We have 3 main entities in pricing OData api:
A_SlsPrcgConditionRecord
A_SlsPrcgCndnRecdValidity
A_SlsPrcgCndnRecordScale
- We will not have the option to pass the condition record number to the evaluating legitimacy element OData call, in light of the fact that the created condition record number will be different in ECC and S4.
- In the following substance modifier step, we will store the condition record number (if exists for that blend), material, cost list type, ETag (ETag is fundamental for while refreshing the information in S4).
- The router next to it, is for determining Create or Update operation.
Create – Default branch
Update – ${property.ECCMaterial} = ${property.S4Material} and ${property.ECCCondType} = ${property.S4CondType}
Contrasting the ECC Material, ECC Condition type which we get from source IDOC with the S4 GET Call results.
Create Condition Record
First message planning is for source IDOC design to ODATA Programming interface POST structure.
Each of the 3 substances should be planned.
In the following stage we are logging the payload and posting the information through OData connector – POST activity.
The last happy modifier holds the vacant body, as displayed underneath. The explanation is on the grounds that we utilize splitter and assemble. Assemble step is utilized in the update branch, which will anticipate that all branches should consolidate at one spot. Subsequently, we should course the make activity end move toward the accumulate step at the update branch.
Update Condition Record
In the update branch, we would plan the IDOC design to the ODATA Programming interface Fix structure. The issue in the Update activity is, we will not have the option to plan all elements in a single planning. For every substance we have pass esteems independently.
For update, we will pass the payload in JSON design through HTTP connector – Cluster Mode. In group mode, we can pass various elements and various tasks in a single exchange.
As we are passing in JSON design, we should utilize XML to JSON transformation capability. Before that step, we will utilize a channel to eliminate the root hub.
In the subsequent stage, we are utilizing cool to change over the legitimacy end date organization to URL encoded design, as we should pass this field esteem in the clump URI. This changed over esteem is put away as a property.
import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import java.net.URLEncoder;
def Message processData(Message message) {
// get properties
def map = message.getProperties();
//get validityenddate value
def value = map.get("ECCConditionValidityEndDate");
//conversion
def encodedURL = URLEncoder.encode(value, "UTF-8");
//Set Properties
message.setProperty("ECCConditionValidityEndDate_encoded", encodedURL);
//return the converted value
return message;
}
There is a constraint while doing XML to JSON change. All values are changed over completely to string rather than Boolean or Whole number. Consequently, we are adding another content to deal with the transformation.
import com.sap.gateway.ip.core.customdev.util.Message
import groovy.json.JsonSlurper
import groovy.json.JsonOutput
def Message processData(Message message) {
def body = message.getBody(java.lang.String) as String
def json = new JsonSlurper().parseText(body)
json.ConditionIsDeleted = json.ConditionIsDeleted.toBoolean()
message.setBody(JsonOutput.toJson(json))
return message
}
We are putting away the fundamental substance JSON payload in the substance modifier. In the subsequent stage, we have added a cycle call which will connect it to the neighborhood reconciliation process.
Neighborhood Coordination process:
These 2 GET calls are to the Valuing Condition record primary element and to the scale’s substance. This is required for getting the ETag of both the elements, which is required for update activity.
Close to the cycle call, we have a switch to check in the event that scales exists or not. Assuming it exists, we will erase the current scales and make new scales. There is no such thing as on the off chance that it and in the source payload, then it will make scales.
Scales creation and cancellation is dealt with in the different neighborhood coordination process, which will be called through process call.
Scales make condition – ${property.ConditionRecord} != ” and ${property.ScaleEtag} = ” and ${property.ConditionScaleQuantity} != “
[ Condition record exists and no current scales information in S4 and, in the source IDOC payload scales information exists]
Scales Erase condition – ${property.ConditionRecord} != ” and ${property.ScaleEtag} != ” [ Condition record exists, and scales exists in S4]
When the scales information is made, the clump payload is set in the following stage of the substance modifier.
Every substance is isolated by each changeset. So that, assuming any of the element fizzles, rest of the substance doesn’t get impacted.
--batch
Content-Type: multipart/mixed; boundary=changeset1
--changeset1
Content-Type: application/http
Content-Transfer-Encoding: binary
PATCH A_SlsPrcgConditionRecord('${property.ConditionRecord}') HTTP/1.1
Content-Type: application/json
If-Match: W/"'${property.RecordEtag}'"
${property.patchPayload}
--changeset1--
--batch
Content-Type: multipart/mixed; boundary=changeset_2
--changeset_2
Content-Type: application/http
Content-Transfer-Encoding: binary
PATCH A_SlsPrcgCndnRecdValidity(ConditionRecord='${property.ConditionRecord}',ConditionValidityEndDate=datetime'${property.ECCConditionValidityEndDate_encoded}') HTTP/1.1
Content-Type: application/json
If-Match: W/"'${property.ValidityEtag}'"
{
"ConditionValidityEndDate": "${property.ECCConditionValidityEndDate}",
"ConditionValidityStartDate": "${property.ECCConditionValidityStartDate}"
}
--changeset_2--
--batch
Content-Type: multipart/mixed; boundary=changeset_3
${property.CreateScalesPayload}
--changeset_3--
It is associated with the Accumulate step. Then, at that point, it is passed to the HTTP connector, which is taken care of in a different cycle call.
In this cycle, we will do a HTTP HEAD call to get the treat subtleties. Then, at that point, HTTP POST activity.
As the bunch activity returns 202 status code, this isn’t refreshed in ECC IDOC status as a triumph. Thus, we are deliberately setting the HTTP status code to 200.
By this method, we are completing the SAP CPI Project IFlow Walkthrough 2 – Replicate Sales Pricing Condition records from ECC to S4HANA. Remember to include the exception subprocess in the main integration process as well as in the local integration process. You can create a local integration process for exceptions and call it in all exception subprocesses.
Trust you’ve perceived the IFlow created for reproducing condition records. Much appreciated. Blissful learning!
YOU MAY BE INTERESTED IN
Top SAP ABAP Interview Questions (2024)
WhatsApp us