SAP Community - Cloud Integration

Cloud Integration: AMQP Adapter, Client Certificate, Solace PubSub+ [4]: iFlow

2024-03-25T12:29:22.712000+01:00

SAP Cloud Integration (aka CPI) allows to send messages from an iFlow to an Event Broker via AMQP.
The AMQP adapter can be configured with Basic Authentication or with Client Certificate.
This blog post shows how to configure client certificate authentication in iFlow for sending messages to Solace PubSub+ Event Broker.

Overview

Part 1: Introduction
Part 2 : Create Client Certificate Chain
Part 3 : Configure Solace
Part 4 : Configure CPI (this blog post)
4.1. Upload Certificate Chain
4.2. Create iFlow
4.3. Run Scenario

Part 4: CPI

Finally, all of the tutorial up to now was done to get a successful iFlow execution.
In CPI, just 2 tasks are waiting for us:

Upload the security artifact (key and chain in p12 file)
Create iFlow

Both build upon the previous sections.

4.1. Upload certificate chain to CPI Keystore

We have to make our private key and the certificate (chain) available on CPI.
To do so, we upload the p12 file (created in section 1.4) to the Keystore in CPI.

We logon to our tenant, then navigate to
“Monitor -> Integratons -> Manage Security -> Keystore”
Press “Add -> Keystore”
“Browse” to c:\solace\demostore.p12
Enter the password “abcd”
Press “Deploy”.

Afterwards, we can check the uploaded artifact:

We can see the chain with all the 3 certificates and corresponding metadata.

4.2. Create iFlow

We create a simple iFlow which does really nothing but sending messages to the Solace Event Broker.
It does even less than that: we don’t even need a message body.
Just make sure that the authentication works fine.

🔶 The iFlow is triggered once after deploy, by a "Timer" start event.

🔶The adapter is of type AMQP and Transport Protocol: TCP
🔸 Connection Tab
Host: copy & paste from solace connection data (see chapter 2.4. above)
Remove the protocol and the port from the copied URI
Port: Paste the port 5671
Authentication: Client Certificate
Private Key Alias: "democlient" (copied from the CPI Keystore)
This is the name which we gave in the openssl pkc12 command.

🔸Processing Tab
Here we have to configure that target as “Queue”
Enter the name, which in our example was the nice name “demo”:

That’s it already about iFlow configuration.
(See here for "Advanced Event Mesh" adapter)

Summary
🔹We need the URL from Solace "Connection" tab.
🔹We need the alias name from CPI Keystore.

4.3. Run Scneario

Now we can deploy the iFlow and check the result:
1. In CPI : The log at “Monitor Message Processing” should show success message:

2. In event broker: The number of “Messages Queued” should have increased:

With that we can be happy.
🙂
We just wanted to see how certificate-based authentication can be realized with CPI and Solace via AMQP adapter.

Troubleshooting

If you get below error, don't be surprised, the text is misleading.
The reason probably: The CA certificate is missing in Solace.
Or the intermediate certificate is not being sent to solace.

org.apache.qpid.jms.exceptions.JMSSecuritySaslException:
Client failed to authenticate using SASL: EXTERNAL

Summary

In this tutorial we’ve learned how to configure client certificate authentication for connecting CPI to Solace Event Broker.
We’re tried to cover nearly all involved steps.
Including:
🔹Understanding some basic knowledge about certificates.
🔹Creating and validating a certificate chain with OpenSSL.
🔹Configuring CBA in Solace.
🔹Configuring CBA in CPI
(See here for "Advanced Event Mesh" adapter)

Quick Guide

🔷Certificate Chain:
🔹The intermediate certificate must have CA:TRUE
🔹The verify command is executed against the chain.
🔹The chain must be packed into the container (p12 or jks).
🔹The chain order: Root Rear.
🔷OpenSSL:
🔹Use -extfile option.
🔹Build intermediate chain.
🔹Apply verify command.
🔷Solace:
🔹Upload the root cert.
🔹Create username equal to “CN”.
🔹Username must be set to "Enabled".
🔷CPI:
🔹Upload the chain, not only client cert.
Reason: the chain must be sent to Solace, as at Solace only the root is known.

🎉🎉🎉🎉🎉🎉🎉

Beginner's Guide to Integration Advisor

2024-03-25T16:24:00.201000+01:00

Introduction:

In this blog post, I will show a simple scenario using B2B integration advisor.

Pre-requisite:

Check this blog post for initial context: Beginner's Guide to EDI Integration

To have understanding of overall features, check out this blog post: Overview of components in Integration Advisor

Scenario:

In this demo scenario, incoming EDI 850 is converted to custom sales order message.

The below is the sample input EDI 850. Please note, the below EDI does not represent/contain production data. It is fake data.

ISA*00*          *00*          *ZZ*AB01000000001  *ZZ*CD01000000002  *030415*1314*U*00401*000601830*1*T*>~
GS*PO*AB01000000001*CD01000000002*20030415*1314*000341219*X*004010~
ST*850*0001~
BEG*00*DS*HW20240312**20220921*0332014937~
CUR*BY*USD~
REF*CO*0232014937~
REF*EU*2244460-DKM-0922~
PER*BD*HWPROCUREMENT3*TE*630-295-7512~
PER*IC*STEVE SMITH*TE*789-213-4444*EM*steve.smith@cao.com~
FOB*DE~
DTM*002*20220920~
TD5**2*FDE4**FedEx Ground*******CG~
N1*BT*INSIGHT DIRECT USA, INC.~
PER*AP*ORDER FLOW TEAM*TE*480-333-3000*EM*LICENSING@INSIGHT.COM~
N1*ST*Park Place Corporate Office*92*0021793569~
N2*Tayrum Steve MITCHELL~
N3*3533330 PHELPS DR~
N4*IRVING*TX*750386507*US~
PER*IC*Dayrum Keith MITCHELL*TE*2149959713~
PO1*00010*6*EA*228.41*CP*BP*DDDDELL-P22D22H*VP*9FDDDDDZ828~
CTT*1~
SE*20*0001~
ST*850*0002~
BEG*00*DS*LC20240312**20220922*0332024801~
CUR*BY*USD~
REF*CO*0332424801~
REF*EU*450176628677~
PER*BD*Licensing 7*TE*567-222-5698*FX*480-760-6126~
FOB*DE~
CSH*BK~
DTM*002*20220921~
TD5**2*UPSS**UPS Ground*******CG~
N1*BT*INSIGHT DIRECT USA, INC.~
PER*AP*ORDER FLOW TEAM*TE*480-333-3000*EM*LICENSING@INSIGHT.COM~
N1*ST*Sam Andersen*92*0010395441~
N3*3457 DASON AVE~
N4*DOCATELLO*ID*832042037*US~
PER*IC*STEVE SMITH*TE*847-402-5000~
PO1*00010*1*EA*433.67*CP*BP*ESD-DDD809A-G00-15.0*VP*6DDDTP459~
PO1*00020*1*EA*433.67*CP*BP*ESD-DDD809A-F00-15.0*VP*6EDDTP459~
PER*FF*JILL CARTER*TE*687-402-4247*EM*JCARTER@ALLSTATE.COM~
DTM*092*20220921~
DTM*093*20230921~
CTT*2~
SE*23*0002~
GE*2*000341219~
IEA*1*000601830~

Each ST segment will create one target SalesOrder structure.

As in the sample data, it has 2 ST-SE segment pair, it will generate 2 message for target.

Expected output for 1st ST segment:

<?xml version="1.0" encoding="UTF-8"?>
<POEnvelope>
<EDIHeader>
<SenderID>AB01000000001 </SenderID>
<ISAControlNum>000601830</ISAControlNum>
<GrpControlNum>000341219</GrpControlNum>
<TxnCntrlNum>0001</TxnCntrlNum>
</EDIHeader>
<PO>
<Header>
<PONum>HW20240312</PONum>
<PODate>2022-09-21</PODate>
<POType>Original</POType>
<CustomerOrderNum/>
<EndUserOrderNum/>
<RequestedDate>2022-09-20</RequestedDate>
<ShipTo>
<Name>Park Place Corporate Office</Name>
<Address>IRVING,TX,750386507,US</Address>
</ShipTo>
<BillTo>
<Name>INSIGHT DIRECT USA, INC.</Name>
</BillTo>
<BuyerInfo>
<Department>HWPROCUREMENT3</Department>
<Telephone>630-295-7512</Telephone>
</BuyerInfo>
<ContactInfo>
<Department>STEVE SMITH</Department>
<Telephone>789-213-4444</Telephone>
<Email>steve.smith@cao.com</Email>
</ContactInfo>
</Header>
<Items>
<Item pos="1">
<ItemNum>00010</ItemNum>
<Quantity>6</Quantity>
<UoM>EA</UoM>
<BuyerPartNo>DDDDELL-P22D22H</BuyerPartNo>
<SellerPartNo>9FDDDDDZ828</SellerPartNo>
</Item>
</Items>
</PO>
</POEnvelope>

For 2nd ST segment,

<?xml version="1.0" encoding="UTF-8"?>
<POEnvelope>
<EDIHeader>
<SenderID>AB01000000001 </SenderID>
<ISAControlNum>000601830</ISAControlNum>
<GrpControlNum>000341219</GrpControlNum>
<TxnCntrlNum>0002</TxnCntrlNum>
</EDIHeader>
<PO>
<Header>
<PONum>LC20240312</PONum>
<PODate>2022-09-22</PODate>
<POType>Original</POType>
<CustomerOrderNum/>
<EndUserOrderNum/>
<RequestedDate>2022-09-21</RequestedDate>
<ShipTo>
<Name>Sam Andersen</Name>
<Address>DOCATELLO,ID,832042037,US</Address>
</ShipTo>
<BillTo>
<Name>INSIGHT DIRECT USA, INC.</Name>
</BillTo>
<BuyerInfo>
<Department>Licensing 7</Department>
<Telephone>567-222-5698</Telephone>
<Fax>480-760-6126</Fax>
</BuyerInfo>
</Header>
<Items>
<Item pos="1">
<ItemNum>00010</ItemNum>
<Quantity>1</Quantity>
<UoM>EA</UoM>
<BuyerPartNo>ESD-DDD809A-G00-15.0</BuyerPartNo>
<SellerPartNo>6DDDTP459</SellerPartNo>
</Item>
<Item pos="2">
<ItemNum>00020</ItemNum>
<Quantity>1</Quantity>
<UoM>EA</UoM>
<BuyerPartNo>ESD-DDD809A-F00-15.0</BuyerPartNo>
<SellerPartNo>6EDDTP459</SellerPartNo>
</Item>
</Items>
</PO>
</POEnvelope>

Integration Advisor

Step 1:

Create MIG (Message Implementation Guideline) for source message. Use 'Get Proposal' option to get proposals.

Based on the requirement, the nodes are qualified, for example, N1 segment - one is for Bill-To Party, another one is for Ship-To Party.

Target system can only accept PO number as max length of 20 chars. Also, PO number will either start with HW or LC. The below checks are applied.

Another example is it allows to set status. If we want some fields to be further validated by reviewer, mark those status as 'For review'.

Here, only the below currency codes are selected from standard ISO code list.

Step 2:

Create Custom Message for target custom PO message structure.

Then create MIG based for the create custom message.

In target side, we want PO Date to be in format 'YYYY-MM-DD'.

Step 3:

Create a MIG Code list.

And assign this codelist to 'POType' in Target MIG.

Step 4:

Create MAG for mapping source to target. As custom message is used at target, proposal will not give any results.

SenderID, ISAControlNum and GrpControlNum are assigned to arbitrary constant values, which later will be changed in iflow.

For POType, code value mapping is used. The criteria to use code value mapping is both source and target field (leaf nodes) should be assigned to a codelist.

Address should be like - City Name,State or Province Code,Postal Code,Country Code

To get position,

Step 5:

Download the cloud integration runtime artifacts or use 'Inject' functionality.

Step 6:

For flow design, refer to standard template 'EDI Integration Templates for SAP Integration Advisor'.

The below is the custom iflow for this scenario.

1. Content Modifier:

Input EDI 850 message

2. EDI Splitter:

It will split the incoming message based on based on number of ST segments. Also, it can be used to auto generate acknowledgement.

Validate Message option checks if it the EDI document is valid. For example, if SE01 contains incorrect count, it will send a negative acknowledgement and stop the processing.

For example, if 2nd SE02 contains incorrect count, all ST segments are rejected as Transaction mode is 'Interchange'.

Now, if we change Transaction mode to 'Message', 1st one will be accepted and 2nd one will be rejected.

Create Acknowledgement is based on 'Check EDI Envelop' i.e, ISA14. As ISA14 value is 1, the EDI 997 message is generated.

For Interchange number in EDI 997, Number Range is used.

The next value will be using for the incoming unique message (determined based on ISA13). If the message is duplicate, the same value will be used in EDI 997.

The output of EDI Splitter as per current configuration, 2 EDI 850 message and 1 EDI 997 message.

For EDI 997, standard header 'EDI_ACKNOWLEDGEMENT' value is true.

The below headers are generated due to EDI Splitter step.

3. Router:

4. EDI to XML Converter:

<?xml version="1.0" encoding="ISO-8859-1"?><ns0:Interchange xmlns:ns0="urn:sap.com:typesystem:b2b:116:asc-x12:004010">
    <S_ISA>
        <D_I01>00</D_I01>
        <D_I02>          </D_I02>
        <D_I03>00</D_I03>
        <D_I04>          </D_I04>
        <D_I05_1>ZZ</D_I05_1>
        <D_I06>AB01000000001  </D_I06>
        <D_I05_2>ZZ</D_I05_2>
        <D_I07>CD01000000002  </D_I07>
        <D_I08>030415</D_I08>
        <D_I09>1314</D_I09>
        <D_I10>U</D_I10>
        <D_I11>00401</D_I11>
        <D_I12>000601831</D_I12>
        <D_I13>1</D_I13>
        <D_I14>T</D_I14>
        <D_I15>&gt;</D_I15>
    </S_ISA>
    <FunctionalGroup>
        <S_GS>
            <D_479>PO</D_479>
            <D_142>AB01000000001</D_142>
            <D_124>CD01000000002</D_124>
            <D_373>20030415</D_373>
            <D_337>1314</D_337>
            <D_28>000341219</D_28>
            <D_455>X</D_455>
            <D_480>004010</D_480>
        </S_GS>
        <M_850>
            <S_ST>
                <D_143>850</D_143>
                <D_329>0001</D_329>
            </S_ST>
            <S_BEG>
                <D_353>00</D_353>
                <D_92>DS</D_92>
                <D_324>HW20240312</D_324>
                <D_373>20220921</D_373>
                <D_367>0332014937</D_367>
            </S_BEG>
            <S_CUR>
                <D_98>BY</D_98>
                <D_100>USD</D_100>
            </S_CUR>
            <S_REF>
                <D_128>CO</D_128>
                <D_127>0232014937</D_127>
            </S_REF>
            <S_REF>
                <D_128>EU</D_128>
                <D_127>2244460-DKM-0922</D_127>
            </S_REF>
            <S_PER>
                <D_366>BD</D_366>
                <D_93>HWPROCUREMENT3</D_93>
                <D_365>TE</D_365>
                <D_364>630-295-7512</D_364>
            </S_PER>
            <S_PER>
                <D_366>IC</D_366>
                <D_93>STEVE SMITH</D_93>
                <D_365>TE</D_365>
                <D_364>789-213-4444</D_364>
                <D_365_2>EM</D_365_2>
                <D_364_2>steve.smith@cao.com</D_364_2>
            </S_PER>
            <S_FOB>
                <D_146>DE</D_146>
            </S_FOB>
            <S_DTM>
                <D_374>002</D_374>
                <D_373>20220920</D_373>
            </S_DTM>
            <S_TD5>
                <D_66>2</D_66>
                <D_67>FDE4</D_67>
                <D_387>FedEx Ground</D_387>
                <D_284>CG</D_284>
            </S_TD5>
            <G_N1>
                <S_N1>
                    <D_98>BT</D_98>
                    <D_93>INSIGHT DIRECT USA, INC.</D_93>
                </S_N1>
                <S_PER>
                    <D_366>AP</D_366>
                    <D_93>ORDER FLOW TEAM</D_93>
                    <D_365>TE</D_365>
                    <D_364>480-333-3000</D_364>
                    <D_365_2>EM</D_365_2>
                    <D_364_2>LICENSING@INSIGHT.COM</D_364_2>
                </S_PER>
            </G_N1>
            <G_N1>
                <S_N1>
                    <D_98>ST</D_98>
                    <D_93>Park Place Corporate Office</D_93>
                    <D_66>92</D_66>
                    <D_67>0021793569</D_67>
                </S_N1>
                <S_N2>
                    <D_93>Tayrum Steve MITCHELL</D_93>
                </S_N2>
                <S_N3>
                    <D_166>3533330 PHELPS DR</D_166>
                </S_N3>
                <S_N4>
                    <D_19>IRVING</D_19>
                    <D_156>TX</D_156>
                    <D_116>750386507</D_116>
                    <D_26>US</D_26>
                </S_N4>
                <S_PER>
                    <D_366>IC</D_366>
                    <D_93>Dayrum Keith MITCHELL</D_93>
                    <D_365>TE</D_365>
                    <D_364>2149959713</D_364>
                </S_PER>
            </G_N1>
            <G_PO1>
                <S_PO1>
                    <D_350>00010</D_350>
                    <D_330>6</D_330>
                    <D_355>EA</D_355>
                    <D_212>228.41</D_212>
                    <D_639>CP</D_639>
                    <D_235>BP</D_235>
                    <D_234>DDDDELL-P22D22H</D_234>
                    <D_235_2>VP</D_235_2>
                    <D_234_2>9FDDDDDZ828</D_234_2>
                </S_PO1>
            </G_PO1>
            <G_CTT>
                <S_CTT>
                    <D_354>1</D_354>
                </S_CTT>
            </G_CTT>
            <S_SE>
                <D_96>20</D_96>
                <D_329>0001</D_329>
            </S_SE>
        </M_850>
        <S_GE>
            <D_97>1</D_97>
            <D_28>000341219</D_28>
        </S_GE>
    </FunctionalGroup>
    <S_IEA>
        <D_I16>1</D_I16>
        <D_I12>000601831</D_I12>
    </S_IEA>
</ns0:Interchange>

<?xml version="1.0" encoding="ISO-8859-1"?><ns0:Interchange xmlns:ns0="urn:sap.com:typesystem:b2b:116:asc-x12:004010">
    <S_ISA>
        <D_I01>00</D_I01>
        <D_I02>          </D_I02>
        <D_I03>00</D_I03>
        <D_I04>          </D_I04>
        <D_I05_1>ZZ</D_I05_1>
        <D_I06>AB01000000001  </D_I06>
        <D_I05_2>ZZ</D_I05_2>
        <D_I07>CD01000000002  </D_I07>
        <D_I08>030415</D_I08>
        <D_I09>1314</D_I09>
        <D_I10>U</D_I10>
        <D_I11>00401</D_I11>
        <D_I12>000601831</D_I12>
        <D_I13>1</D_I13>
        <D_I14>T</D_I14>
        <D_I15>&gt;</D_I15>
    </S_ISA>
    <FunctionalGroup>
        <S_GS>
            <D_479>PO</D_479>
            <D_142>AB01000000001</D_142>
            <D_124>CD01000000002</D_124>
            <D_373>20030415</D_373>
            <D_337>1314</D_337>
            <D_28>000341219</D_28>
            <D_455>X</D_455>
            <D_480>004010</D_480>
        </S_GS>
        <M_850>
            <S_ST>
                <D_143>850</D_143>
                <D_329>0002</D_329>
            </S_ST>
            <S_BEG>
                <D_353>00</D_353>
                <D_92>DS</D_92>
                <D_324>LC20240312</D_324>
                <D_373>20220922</D_373>
                <D_367>0332024801</D_367>
            </S_BEG>
            <S_CUR>
                <D_98>BY</D_98>
                <D_100>USD</D_100>
            </S_CUR>
            <S_REF>
                <D_128>CO</D_128>
                <D_127>0332424801</D_127>
            </S_REF>
            <S_REF>
                <D_128>EU</D_128>
                <D_127>450176628677</D_127>
            </S_REF>
            <S_PER>
                <D_366>BD</D_366>
                <D_93>Licensing 7</D_93>
                <D_365>TE</D_365>
                <D_364>567-222-5698</D_364>
                <D_365_2>FX</D_365_2>
                <D_364_2>480-760-6126</D_364_2>
            </S_PER>
            <S_FOB>
                <D_146>DE</D_146>
            </S_FOB>
            <S_CSH>
                <D_563>BK</D_563>
            </S_CSH>
            <S_DTM>
                <D_374>002</D_374>
                <D_373>20220921</D_373>
            </S_DTM>
            <S_TD5>
                <D_66>2</D_66>
                <D_67>UPSS</D_67>
                <D_387>UPS Ground</D_387>
                <D_284>CG</D_284>
            </S_TD5>
            <G_N1>
                <S_N1>
                    <D_98>BT</D_98>
                    <D_93>INSIGHT DIRECT USA, INC.</D_93>
                </S_N1>
                <S_PER>
                    <D_366>AP</D_366>
                    <D_93>ORDER FLOW TEAM</D_93>
                    <D_365>TE</D_365>
                    <D_364>480-333-3000</D_364>
                    <D_365_2>EM</D_365_2>
                    <D_364_2>LICENSING@INSIGHT.COM</D_364_2>
                </S_PER>
            </G_N1>
            <G_N1>
                <S_N1>
                    <D_98>ST</D_98>
                    <D_93>Sam Andersen</D_93>
                    <D_66>92</D_66>
                    <D_67>0010395441</D_67>
                </S_N1>
                <S_N3>
                    <D_166>3457 DASON AVE</D_166>
                </S_N3>
                <S_N4>
                    <D_19>DOCATELLO</D_19>
                    <D_156>ID</D_156>
                    <D_116>832042037</D_116>
                    <D_26>US</D_26>
                </S_N4>
                <S_PER>
                    <D_366>IC</D_366>
                    <D_93>STEVE SMITH</D_93>
                    <D_365>TE</D_365>
                    <D_364>847-402-5000</D_364>
                </S_PER>
            </G_N1>
            <G_PO1>
                <S_PO1>
                    <D_350>00010</D_350>
                    <D_330>1</D_330>
                    <D_355>EA</D_355>
                    <D_212>433.67</D_212>
                    <D_639>CP</D_639>
                    <D_235>BP</D_235>
                    <D_234>ESD-DDD809A-G00-15.0</D_234>
                    <D_235_2>VP</D_235_2>
                    <D_234_2>6DDDTP459</D_234_2>
                </S_PO1>
            </G_PO1>
            <G_PO1>
                <S_PO1>
                    <D_350>00020</D_350>
                    <D_330>1</D_330>
                    <D_355>EA</D_355>
                    <D_212>433.67</D_212>
                    <D_639>CP</D_639>
                    <D_235>BP</D_235>
                    <D_234>ESD-DDD809A-F00-15.0</D_234>
                    <D_235_2>VP</D_235_2>
                    <D_234_2>6EDDTP459</D_234_2>
                </S_PO1>
                <S_PER>
                    <D_366>FF</D_366>
                    <D_93>JILL CARTER</D_93>
                    <D_365>TE</D_365>
                    <D_364>687-402-4247</D_364>
                    <D_365_2>EM</D_365_2>
                    <D_364_2>JCARTER@ALLSTATE.COM</D_364_2>
                </S_PER>
                <S_DTM>
                    <D_374>092</D_374>
                    <D_373>20220921</D_373>
                </S_DTM>
                <S_DTM>
                    <D_374>093</D_374>
                    <D_373>20230921</D_373>
                </S_DTM>
            </G_PO1>
            <G_CTT>
                <S_CTT>
                    <D_354>2</D_354>
                </S_CTT>
            </G_CTT>
            <S_SE>
                <D_96>23</D_96>
                <D_329>0002</D_329>
            </S_SE>
        </M_850>
        <S_GE>
            <D_97>1</D_97>
            <D_28>000341219</D_28>
        </S_GE>
    </FunctionalGroup>
    <S_IEA>
        <D_I16>1</D_I16>
        <D_I12>000601831</D_I12>
    </S_IEA>
</ns0:Interchange>

5. XSLT Mapping:

This step will add qualifier to the node names using preproc.xsl.

6. XML Validator:

For example, If PO Number does not start with HW or LC, it will throw an error.

7. XSLT Mapping:

To convert source structure to target structure.

8. XSLT Mapping:

XSLT mapping to populate control number for reference in target message.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet version="3.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:xs="http://www.w3.org/2001/XMLSchema" exclude-result-prefixes="#all">
   <xsl:mode on-no-match="shallow-copy" />
   <xsl:output method="xml" indent="yes" />
   <xsl:param name="SAP_EDI_Interchange_Control_Number" as="xs:string" />
   <xsl:param name="SAP_EDI_GS_Control_Number" as="xs:string" />
   <xsl:param name="SAP_EDI_Sender_ID" as="xs:string" />
   <xsl:param name="SAP_ST_Control_Number" as="xs:string" />
   <xsl:template match="/POEnvelope/EDIHeader/SenderID">
      <xsl:copy>
         <xsl:value-of select="$SAP_EDI_Sender_ID" />
      </xsl:copy>
   </xsl:template>
   <xsl:template match="/POEnvelope/EDIHeader/ISAControlNum">
      <xsl:copy>
         <xsl:value-of select="$SAP_EDI_Interchange_Control_Number" />
      </xsl:copy>
   </xsl:template>
   <xsl:template match="/POEnvelope/EDIHeader/GrpControlNum">
      <xsl:copy>
         <xsl:value-of select="$SAP_EDI_GS_Control_Number" />
      </xsl:copy>
   </xsl:template>
   <xsl:template match="EDIHeader">
      <xsl:copy>
         <xsl:apply-templates select="@*|node()"/>
         <TxnCntrlNum>
            <xsl:value-of select="$SAP_ST_Control_Number" />
         </TxnCntrlNum>
      </xsl:copy>
   </xsl:template>
</xsl:stylesheet>

Reverse Flow:

The below shows the steps for SOAP to EDI coversion.

SOAP Pre-processing to add qualifier to the node name using source MIG preproc XSL
SOAP to X12 mapping using MAG xsl
XSLT mapping to get the count for SE01 segment
XML validator using <Target_MIG>_RD.xsd
Content modifier to set ISA and GS segment values.
XML to EDI converter to convert EDI-XML to EDI.

Reference Link:

SAP Integration Advisor

Regards,

Priyanka Chakraborti

SAP Integration Suite – Access Policies for Integration Packages

2024-03-25T18:55:44.335000+01:00

As of increment 2401 of SAP Integration Suite, you can define access policies for integration packages. This extension makes the lives of tenant administrators easier who need to manage large numbers of integration packages and selectively restrict access to integration content for different user groups.

Short reminder of what Access Policies are:

With an access policy, you can protect groups of integration artifacts against undesired access. You define access policies as described in SAP Help Portal under Managing Access Policies | SAP Help Portal.

For example, you can define an access policy for all integration flows that fulfil the condition: name contains the string ‘Read’. As consequence, all integration flows that meet this condition are protected against unauthorized access.

Protection against unauthorized access covers:

All operations on the design time artifacts (such like editing, saving, or deploying an artifact, for example)
All operations on the deployed runtime artifacts (like restarting an artifact, for example)
Data that is processed or stored by the artifacts (like business data stored for monitoring purposes or stored by integration flows in local data stores or variables)

To enable dedicated users to access these protected artifacts, a role needs to be defined in SAP Business Technology Platform (SAP BTP) cockpit that is associated with the access policy (for more information, see the online documentation).

Access policies can be defined for all available integration artifact types such like integration flows, value mappings, and so forth.

Back to the new feature introduced with increment 2401.

When you open the access policy screen in the Monitor > Integrations and APIs section of SAP Integration Suite (Access Policies tile), you now notice that you can also select Integration Package as Type:

Using this new option, you only need to specify one single artifact reference to protect all artifacts of an integration package. In the example above, an artifact reference for the integration package with the name My First Integration Package is defined.

You now also understand to what extent the extension makes the life of the tenant administrator easier, whom we talked about earlier:

If you like to protect all artifacts in a dedicated integration package, you can now define an access policy with one single artifact reference. Before this enhancement, you needed to create an individual artifact references for each integration artifact type separately.

Use Cases

You may be wondering in which cases it makes sense to define access policies for integration packages. Let me point out the following rule of thumb:

Option	Use Case
Define access policy for an integration package …	If you like to protect all the artifacts of an integration package (including artifacts of all types).
Define access policy for individual artifact types (for example, integration flows and value mappings) …	If you like to protect only few, but not all artifacts of the integration package.

Compatibility with Access Policies for Specific Artifact Types

As said, an access policy for an integration package affects the access to all artifact types contained in the package. However, you can still define access policies for individual artifact types. Now the following can happen: you may want to define an access policy for a specific integration package that contains artifacts for which other, artifact type-specific access policies exist already. What happens in such a case? The message at the top of the dialog provides a clue: for compatibility reasons, existing access policies for individual artifact types will remain intact when you define an access policy for an integration package. Access policies for dedicated artifact types co-exist with access policies on integration package level. Or, phrased differently: When you define an access policy for an integration package that contains artifacts that are also protected by another access policy (for example, by an access policy for a specific group of integration flows), the latter remain valid as well. The message prompts you to check if access policies have already been defined for specific artifacts in your package that you want to protect as a whole.

Let's see how the co-existence of access policies on integration package and on artifact level affects things in a specific example.

Let’s assume that an integration package is protected by one access policy. Furthermore, this integration package contains an integration flow that is protected by another access policy.

To walk you through the example step-by-step, the following two access policies are defined:

Access Policy Name	Protects
PackageAccess	Artifacts contained in the integration package with the name My First Integration Package
FlowAccess	Integration flows (across all integration packages) with a name that starts with the word Read (matches regular expression ^Read.*)

The tenant has two integration packages with the names My First Integration Package and My Second Integration Package. Both packages contain also integration flows protected by the artifact-related access policy (integration flows with a naming starting with Read).

As a result of this setup, the artifacts are now protected as shown in the following figure:

As we said that access policies protect the specified artifacts – unless a user has a role assigned that is associated with the access policy – we can do the combinatorics with 4 fictitious users with different role assignments:

User	Assigned role	Role associated with access policy*	Can access
User1	Role1 Role2	PackageAccess FlowAccess	All artifacts in all shown integration packages
User2	Role1	PackageAccess	In the package My First Integration Package protected by the package-level access policy: All artifacts In the non-protected package My Second Integration Package: all artifacts, unless they are protected by access policy FlowAccess (for which this user has no corresponding role assignment)
User3	Role2	FlowAccess	In the package My First Integration Package protected by the package-level access policy: integration flows that are protected by the access policy FlowAccess. All other artifacts are protected from this user through the package-level access policy PackageAccess. In the non-protected package My Second Integration Package: All artifacts (because here, this user also can access the artifacts protected by the integration flow-related access policy FlowAccess)
User4	(No role assigned)	n.a.	Because this user does not have either of the roles, they are subject to the access restrictions defined by both access policies. As a result, the only artifact they can access is the artifact that is covered by none of the access policies (the non-protected integration flow in the non-protected integration package).

*To be more precise: Role associated with an access policy means: For the Values attribute of the role a string is specified that matches the name of the access policy. For more information on this, check out the online documentation in SAP Help Portal under Creating Custom Roles for Access Policies | SAP Help Portal.

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

2024-03-26T03:57:44.968000+01:00

Unleash the Power of Real-Time Business Insights with SAP Advanced Event Mesh

In today's ever-changing business landscape, being able to respond quickly is crucial. SAP Business Technology Platform (BTP) lays the groundwork for this agility by providing a comprehensive integration platform. But what if you could harness the power of instant reactions to every customer interaction? That's where SAP Advanced Event Mesh (AEM) comes in - a revolutionary tool that unlocks the true potential of SAP BTP. By utilizing the event-driven architecture championed by SAP BTP, AEM empowers businesses to make real-time, data-driven decisions - a vital capability in today's fast-paced environment.

Imagine a world where every customer interaction triggers an immediate response, enabling businesses to make informed choices in real-time. This is the power of SAP Advanced Event Mesh (AEM), a revolutionary tool that transforms how businesses react to events and unlock hidden opportunities .

(Image Source: SAP)

The Grocery Store Scenario: A Glimpse into the Future of Inventory Management

Consider a grocery store where every purchase instantly triggers an event that is relayed to a central system. This eliminates the need for traditional end-of-day reports, allowing for immediate insights into:

Product popularity: Identify fast-selling items and ensure they are always in stock.
Inventory optimization: Replenish stock as soon as it runs low, preventing lost sales and customer frustration.

This is just one example of how AEM streamlines business processes and enables proactive decision-making across various industries.

Key Features of SAP AEM:

Event-driven communication: Respond to events as they happen, creating a dynamic and responsive system.
Scalability and flexibility: Easily adapt to changing business needs and data volumes.
Unified event management: Gain centralized control and visibility over all events within your SAP landscape.
Seamless integration: Integrate seamlessly with SAP and Non-SAP solutions.

Components of SAP AEM:

Mission Control: Easily deploy and manage event brokers, monitor their performance, and visualize your event-driven architecture.

Event Portal: Design your event-driven setup using a full set of tools, including an overview, designer, catalog, and event manager for running events.

Insights: Get real-time insights into the health and performance of your event network, ensuring your applications work well.

Deployment Options:

You can choose from different deployment options for SAP AEM:

Public Regions: This allows you to use the infrastructure managed by SAP, which is simple and easy to use.
Dedicated Regions: This gives you more control and isolation within a dedicated SAP cloud environment.
Customer-Controlled Regions: This lets you deploy AEM on your own Kubernetes cluster, giving you ultimate customization and control

Security:

SAP AEM takes security very seriously at every level, with features like:

Secure cloud architecture with various deployment options.
VPC/VNet isolation for keeping data segregated securely.
Multi-factor authentication and authorization to have comprehensive access control.

Groovy Script to Compare XML Payloads in SAP CPI - Part 1

2024-03-27T12:08:10.456000+01:00

Introduction:

This blog is dedicated to exploring the intricacies of data comparison in SAP CPI implementation scenarios. One of the key challenges in data/message flow optimisation is effectively comparing input payloads. In this blog series, we will focus on comparing two XML payloads, regardless of their structural similarities or differences, with a keen eye on detecting and highlighting data changes.

Scenario :

In SAP CPI implementation scenarios, comparing input payloads is a crucial factor in data/message flow optimisation. In this blog, we delve into the comparison of two XML payloads. Whether the payloads possess different structures or share a similar structure, the focus remains on detecting data changes between the old and updated versions. Our goal is to highlight the updated data segments, ensuring a streamlined
output.

Solution :

Leveraging Groovy Script in the Flow for Data Comparison.

IFlow Design:

Content Modifier : We will provide a dataset of employees in the content modifier named as "Payload input1". Below is the sample data provided.

<?xml version="1.0" encoding="UTF-8"?>
<root>
	<EMPLOYEE>
			<EMPLOYEE_ID>1001</EMPLOYEE_ID>
			<FIRST_NAME>Buggs</FIRST_NAME>
			<LAST_NAME>Bunny</LAST_NAME>
			<EMAIL>BuggsBunny@abc.com</EMAIL>
			<PHONE_NUMBER>212-867-5309</PHONE_NUMBER>
			<HIRE_DATE>12 DEC 1985</HIRE_DATE>
			<JOB_ID>MD12741</JOB_ID>
			<SALARY>4000.00</SALARY>
			<COMMISSION_PCT>0.03</COMMISSION_PCT>
			<DESIGNATION>Developer</DESIGNATION>
			<DEPARTMENT_ID>5341</DEPARTMENT_ID>
	</EMPLOYEE>
	<EMPLOYEE>
			<EMPLOYEE_ID>1002</EMPLOYEE_ID>
			<FIRST_NAME>Robert</FIRST_NAME>
			<LAST_NAME>Jay</LAST_NAME>
			<EMAIL>RobertJay@abc.com</EMAIL>
			<PHONE_NUMBER>212-867-2345</PHONE_NUMBER>
			<HIRE_DATE>02 JAN 1983</HIRE_DATE>
			<JOB_ID>MD12742</JOB_ID>
			<SALARY>7000.00</SALARY>
			<COMMISSION_PCT>0.13</COMMISSION_PCT>
			<DESIGNATION>Consultant</DESIGNATION>
			<DEPARTMENT_ID>5342</DEPARTMENT_ID>
	</EMPLOYEE>
	<EMPLOYEE>
			<EMPLOYEE_ID>1003</EMPLOYEE_ID>
			<FIRST_NAME>Tom</FIRST_NAME>
			<LAST_NAME>Frank</LAST_NAME>
			<EMAIL>TomFrank@abc.com</EMAIL>
			<PHONE_NUMBER>212-867-2342</PHONE_NUMBER>
			<HIRE_DATE>01 OCT 1980</HIRE_DATE>
			<JOB_ID>MD12743</JOB_ID>
			<SALARY>10000.00</SALARY>
			<COMMISSION_PCT>0.23</COMMISSION_PCT>
			<DESIGNATION>Manager</DESIGNATION>
			<DEPARTMENT_ID>5343</DEPARTMENT_ID>
	</EMPLOYEE>
</root>

Content Modifier : We will declare a property named "input1" to store payload1.

Content Modifier : Another dataset of employees will be provided in the content modifier named "Payload input2". However, in this example, the XML data structure is different, and the data has been updated. Below is the sample data provided.

The salary data of the employee with Employee Id 1003 has been updated from <SALARY>10000.00</SALARY> to <SALARY>14000.00</SALARY>.

<?xml version="1.0" encoding="UTF-8"?>
<root>
	<EMPLOYEE>
		<EMPLOYEE_ID>1002</EMPLOYEE_ID>
		<FIRST_NAME>Robert</FIRST_NAME>
		<LAST_NAME>Jay</LAST_NAME>
		<HIRE_DATE>02 JAN 1983</HIRE_DATE>
		<JOB_ID>MD12742</JOB_ID>
		<COMMISSION_PCT>0.13</COMMISSION_PCT>
		<DESIGNATION>Consultant</DESIGNATION>
		<DEPARTMENT_ID>5342</DEPARTMENT_ID>
		<EMAIL>RobertJay@abc.com</EMAIL>
		<PHONE_NUMBER>212-867-2345</PHONE_NUMBER>
		<SALARY>7000.00</SALARY>
	</EMPLOYEE>
	<EMPLOYEE>
		<EMPLOYEE_ID>1001</EMPLOYEE_ID>
		<FIRST_NAME>Buggs</FIRST_NAME>
		<LAST_NAME>Bunny</LAST_NAME>
		<HIRE_DATE>12 DEC 1985</HIRE_DATE>
		<JOB_ID>MD12741</JOB_ID>
		<COMMISSION_PCT>0.03</COMMISSION_PCT>
		<DESIGNATION>Developer</DESIGNATION>
		<DEPARTMENT_ID>5341</DEPARTMENT_ID>
		<EMAIL>BuggsBunny@abc.com</EMAIL>
		<PHONE_NUMBER>212-867-5309</PHONE_NUMBER>
		<SALARY>4000.00</SALARY>
	</EMPLOYEE>
	<EMPLOYEE>
		<EMPLOYEE_ID>1003</EMPLOYEE_ID>
		<FIRST_NAME>Tom</FIRST_NAME>
		<LAST_NAME>Frank</LAST_NAME>
		<HIRE_DATE>01 OCT 1980</HIRE_DATE>
		<JOB_ID>MD12743</JOB_ID>
		<COMMISSION_PCT>0.23</COMMISSION_PCT>
		<DESIGNATION>General Manager</DESIGNATION>
		<DEPARTMENT_ID>5343</DEPARTMENT_ID>
		<EMAIL>TomFrank@abc.com</EMAIL>
		<PHONE_NUMBER>212-867-2342</PHONE_NUMBER>
		<SALARY>14000.00</SALARY>
	</EMPLOYEE>
</root>

Content Modifier : We will declare a property named "input2" to store payload2.

Groovy Script : The Groovy script below compares the data of both payload1 and payload2 based on the Employee Id, which is the unique data identifier. It then returns only the dataset that has been updated or modified compared to the previous data.

import com.sap.gateway.ip.core.customdev.util.Message;
import java.util.HashMap;
import groovy.util.XmlSlurper;
import groovy.xml.MarkupBuilder;


def Message processData(Message message) {

def input1 = message.getProperty("input1")
def input2 = message.getProperty("input2")

def xml1 = new XmlSlurper().parseText(input1)
def xml2 = new XmlSlurper().parseText(input2)

def changedData = []

xml1.EMPLOYEE.each { row1 ->
    def matchingRow = xml2.EMPLOYEE.find { row2 ->
        row1.EMPLOYEE_ID.text() == row2.EMPLOYEE_ID.text()
    }

    if (matchingRow) {
        def diff = false

        row1.children().each { element ->
            def correspondingElement = matchingRow."${element.name()}"
            if (element.text() != correspondingElement.text()) {
                diff = true
            }
        }

        if (diff) {
            changedData << matchingRow
        }
    }
}

def resultXml = new StringWriter()
def xmlBuilder = new MarkupBuilder(resultXml)

xmlBuilder.root {
    changedData.each { changedRow ->
        EMPLOYEE {
            changedRow.children().each { element ->
                "${element.name()}"(changedRow."${element.name()}".text())
            }
        }
    }
}

    message.setBody(resultXml.toString())
    return message;
}

Result :

In conclusion, the output of using Groovy script in the flow for comparing data contains the data of the employee whose dataset has been updated. This approach not only streamlines data comparison processes but also ensures that only relevant and updated information is highlighted, contributing to efficient data/message flow management.

Thanks and Regards,
Gagan H L

Integrating Custom References with Sales Billing by Extending the Integration Flow

2024-03-27T14:05:15.640000+01:00

Introduction

You might already know that you can store references to related data, such as external documents, in SAP Subscription Billing by defining custom references. But did you know that you can transfer those custom references to Sales Billing in SAP S/4HANA Cloud and display them on customer invoices? In this blog we’ll walk you through the steps to set this up.

Example Use Case

You want to enter purchase order references in subscriptions and include those references in the items of billing document requests so the references can be displayed on invoices generated in SAP S/4HANA Cloud.

Before we dive into the setup, here’s a short summary of the concepts:

Custom References and Custom Fields

Billing data in SAP Subscription Billing includes custom references that originate in subscriptions or in customer or product data.
Custom references from SAP Subscription Billing can be mapped to custom fields in SAP S/4HANA Cloud, as we’ll describe in this blog post.

To find out more, browse the following documentation on the SAP Help Portal:
Custom References | Custom Fields

Custom Integration Flows in SAP Cloud Integration

SAP provides standard integration flows that define aspects such as mapping and routing for data integrations. As a customer or partner, you can extend these integration flows, for example to adapt the way data is replicated or to include additional data in replication. If you want to dig into the details of custom integration flows, refer to Integration Flow – Concepts on the SAP Help Portal.

For our example, we’ll show how to extend the integration flow used to transfer bills from SAP Subscription Billing to SAP S/4HANA Cloud.

Configuration Steps

Configure custom fields in SAP S/4HANA Cloud.
Define and use custom references in SAP Subscription Billing.
Extend the standard integration flow in SAP Cloud Integration.
Check that the integration is working correctly.

1. Configure custom fields in SAP S/4HANA Cloud

Create a custom field

To create a customer field, you need a role with all the following business catalogs:

SAP_CORE_BC_EXT_BLE
SAP_CORE_BC_EXT_FLD
SAP_CORE_BC_EXT_FLEX

Open the Custom Fields app and create a custom field Purchase Order. The business context must be Sales: Billing Document Item (SD_BILLINGDOCITEM).

Adapt the user interface to show the new custom field

In the Manage Billing Document Requests app, display a billing document request. Choose the billing document request number to navigate to the Billing Document Requests app. Choose the user option to adapt the UI:
Search for the field Purchase Order and select it:
The field Purchase Order appears on the billing document request item:

2. Define and use custom references in SAP Subscription Billing

Open the Manage Business Configuration app, go to Custom References and define a custom reference for the purchase order. Enable the field for subscriptions and bill items:
Open the Manage Subscriptions app, open a subscription, and navigate to Custom References. Find the custom reference type Purchase Order and enter a purchase order ID/number:
When a bill is generated for the subscription, the bill item contains the custom reference for the purchase order:

3. Extend the standard integration flow in SAP Cloud Integration

To modify the message mapping of the standard integration flow to include the purchase order field, the following steps are required in SAP Cloud Integration:

Download the standard message mapping
Check the post-exit processing in the standard integration flow
Create a custom integration flow
Enable the extension in the standard integration flow

Download the standard message mapping

Start by downloading the standard message mapping from the standard integration flow Transfer Bills to SAP S4HANA Cloud. You need the message mapping to add it your custom integration flow later, where you can modify the mapping.

Check the post-exit processing in the standard integration flow

In the post-exit processing step (Post Processing), display the details of the Bundle Message step:

This step creates a new payload that contains the following:

The original bill and customer payload
The message mapping output

This payload will be passed from the standard integration flow to your custom integration flow. To find out more about post-exits, see Customer Exits in the SAP Cloud Integration documentation.

Create a custom integration flow

Create a custom integration flow with the ProcessDirect adapter and configure an address:
Next we’ll customize the post-exit integration flow.
Enter the following namespace mapping:
xmlns:ns1=http://sap.com/xi/XI/SplitAndMerge
Add a filter to get the original bill response, which is the source of the message mapping:
Upload the message mapping from the standard integration flow:
Download the latest WSDL file from the communication arrangement SAP_COM_0095 and upload it to the custom integration flow:
Modify the message mapping in the custom integration flow for the purchase order field. Map the custom reference ID to it:
Deploy the custom integration flow.

Enable the extension in the standard integration flow

Configure the standard integration flow:
ℹ️ The address must be the same as the address configured in the custom integration flow.
Deploy the standard integration flow.

4. Check that the integration is working correctly

After the next transfer of billing data to SAP S/4HANA Cloud, you see a reference to the subscription billing document request in the Manage Billing Data app:

When you click on the document ID, you jump into the billing document request item, where you can see that the purchase order is displayed:

🏁You've now completed the setup and can include custom references in your customer invoices.

More Information

Cloud Integration: Advanced Event Mesh Adapter, Client Certificate, AEM

2024-03-27T16:13:19.536000+01:00

SAP Cloud Integration (aka CPI) offers an “Advanced Event Mesh Adapter” which is well integrated with the “Advanced Event Mesh” broker.
This article shows how to set up a scenario where we send a message from iFlow via “Advanced Event Mesh Adapter” to SAP Cloud Integration, Advanced Event Mesh (AEM) with Client Certificate Authentication.
Please refer to the sibling article series which describes in detail the setup for "AMQP Adapter".
The creation of a certificate chain is equal in both scenarios.
The configuration in AEM is also same as in Solace.
So basically, in this blog post we only need to show the configuration in the “Advanced Event Mesh” (AEM) adapter.

Overview

Introduction
Create Client Certificate
Configure AEM
Create iFlow
Run Scenario
Key Takeaways

Prerequisites

🔹To follow this tutorial, access to SAP Advanced Event Mesh is required.
🔹Access To CPI Tenant is required
🔹I recommend bookmarking the Security Glossary

1. Introduction

We want to send a message from an iFlow to Advanced Event Mesh Broker.
We want to use the “Advanced Event Mesh” adapter.
Authentication should be configured with client certificate.

There’s a sibling blog post which uses the AMQP adapter for the same use case.
Almost all steps are equal and described in detail there.

What is the scenario?
This is the high-level overview of the simple scenario:

We can see that the iFlow sends messages via "Advanced Event Mesh adapter" to a queue in Advanced Event Mesh.
On both sides, certificates have to be configured.

How to get certificates?
The sibling article series explains in detail multiple ways of generating certificates for this purpose.
To give an overview of some possibilities:

🔷Use CPI Keystore dashboard

1. Create key pair / certificate in CPI
🔹Use it as self-signed root in our scenario
🔹Download the corresponding CSR (certificate signing request) and create a self-signed chain on laptop
🔹Download the CSR and use it to purchase a productive chain from productive CA
2. Download existing CPI client certificate chain and use it for our scenario

🔷Use Laptop

-> Create key pair / certificate ourselves on laptop
🔹Use Openssl
- Create self-signed root or chain (chain with different length)
- Create CSR and purchase productive chain
🔹Use Java Keytool
- etc
🔹Use any other tool
- etc

🔷Use BTP

-> let service broker or IAs generate key pair / certificate chain and use that for our scenario

Alternatively, there are tools in the internet and for download, to handle such tasks.
In the present tutorial, we’re going the easy way and use a CPI-generated certificate.
I recommend however going through the experience of creating certificate chain on local computer.

2. Create Client Certificate

Using the built-in functionality of CPI to generate a key pair has the following advantage:
The private key is generated at CPI, where it is needed.
The private key never leaves CPI (it is not possible to download it)
The private key does not need to be uploaded to CPI via net.
The disadvantage would be that this private key cannot be used locally, as it is not possible to download it.

For today’s article, we’re using the CPI keystore to create a self-signed certificate.
This will serve as trusted root certificate at AEM-side, and it will be used as client-certificate in iFlow.

Ceate Key Pair in CPI

We go to keystore and choose "Create -> Key Pair"
We enter some data of your choice, e.g.
🔸Alias: “demokeypair”
🔸CN: “demokeypair”

It will be used for creating the certificate.

After creation, we click on the new entry I the dashboard to view the details:

We can see that a self-signed certificate has been created.
If subject and issuer DN are equal, then this means it is a root certificate.

Now we can download the new certificate via context button and “Download Certificate”
In my example, a file demokeypair.cer is downloaded to my laptop.

Note:
If you encounter a .p7b file after download artifacts, you can extract it with the help of OpenSSL and the pkcs7 command.

openssl pkcs7 -in demokeypair.p7b -print_certs -out certificate.cer

3. Configure Advanced Event Mesh

Now that we have the client certificate, we can establish trust at AEM side.
This means:
AEM receives an authentication request with a client certificate.
It must validate the certificate.
It must trust it.

To do so, the signature of the issuer is checked – and the issuer itself – continuing the chain up to the root.
If the root is not known by AEM, then it has to be configured.
As such, we have to upload our certificate (which is a root as well) to AEM.

See sibling blog post for detailed description.

3.1. Upload Root Certificate

We go to “Cluster Manager” ➡️ Event Broker service instance ➡️ “Manage” tab.
➡️click “Certificate Authorities” and upload the root certificate from previous chapter.
In my example, we upload the demokeypair.cer file.

3.2. Authorization for Client

We go to “Cluster Manager” ➡️ Event Broker service instance ➡️ “Open Broker Manager”.
➡️ “Access Control” ➡️ “Client Usernames”.
Create new client username and enter the value of the “CN” of our client certificate from previous chapter.
In my example: “demokeypair”

➡️ Press “Create”.
➡️ Press “Enable”.
➡️ Press “Apply”.

3.3. Create Queue

We're still in the “Broker Manager”, so now we choose “Queues” on the left navigation pane.
Then we create a new queue and enter a name of our choice, e.g. “demo”

3.4. Connection Details

To find the connection details that we need in the next chapter, we go to
“Cluster Manager” ➡️ Event Broker service instance ➡️ “Connect” tab.
Expand “Solace Messaging” section (SMF over TCP).
Copy the “Message VPN” and “SMF Host”:

4. Create iFlow

We create a very simple iFlow that does nothing than sending an empty message to Advanced Event Mesh.
See sibling blog post for some more description.

Other than in sibling post, we use the “Advanced Event Mesh” adapter.

Configure Advanced Event Mesh adapter
🔸URL
We need to enter the full URL of the SMF host, which we copied in previous chapter.
Including protocol and port.
Just copy&paste from AEM dashboard (previous chapter).
🔸Message VPN
The Message VPN can also be copied from AEM.
🔸Username
The Username “default” can be used, as it is available on AEM as per default.
But any other existing username can be entered here as well.
🔸Keystore Alias
The Keystore Alias must point to a key pair entry.
It is checked during deployment.
In our example, we enter the key pair which we created in chapter above: “demokeypair”

In the “Processing” Tab, we choose “Queue” and enter the name of the queue we created above:

That’s it, we can save the iFlow.

5. Run Scenario

To run the scenario we just deploy the iFlow.
Then we check the result:
In CPI : The log at “Monitor Message Processing” should show success message.
In event broker: The number of “Messages Queued” should have increased.

6. Quick Guide

🔷Certificate Chain:
🔹The intermediate certificate must have CA:TRUE
🔹The chain order: Root Rear.
🔷AEM:
🔹Upload the root cert.
🔹Create username equal to “CN”.
🔹Username must be set to "Enabled".
🔷CPI:
🔹Upload the chain, not only client cert.
Reason: the whole chain must be sent to AEM, as at AEM only the root is known.

Summary

In this blog post we’ve learned how to deal with client certificates.
We wanted to use certificate-based authentication instead of username / password (Basic Auth).
To do so, we learned how to easily get a key pair and a certificate.
To establish trust, we need to configure the target server (AEM) with the trusted root certificate.
Finally, we can use the certificate in CPI, which means, it is stored in the Keystore and used in the iflow.
In this blog post, we’ve learned how to configure the Advanced Event Mesh adapter.
There’s a sibling article series which explains many details about certificates.

Links

SAP Help Portal landing page : https://help.sap.com/docs/SAP_ADVANCED_EVENT_MESH
Documentation entry page: https://help.pubsub.em.services.cloud.sap/Cloud/cloud-lp.htm

🎉🎉🎉🎉🎉🎉🎉

New Partner Content on SAP Business Accelerator Hub (Q1 ’24)

2024-04-03T10:59:59.828000+02:00

As a continuation of the previous blog, we would like to provide further updates and keep up the momentum of sharing relevant information with our community.

In this blog series, learn about the new content published on SAP Business Accelerator Hub from our partners during Q1 '2024, along with their high-level details.

For complete details on each partner's content, refer to the partners listing which is available on the home page of SAP Business Accelerator Hub.

-----------------------------------------------------------------------------------------------------------------------------------------------

Flexso NV

Flexso specializes in advanced SAP solutions, driving innovation and efficiency for your business. We blend your goals with our expertise, offering a comprehensive suite of services including SAP S/4HANA, HR digitalization, customer experience enhancement, and more. As a proactive partner, we focus on transforming your business for agility and future readiness, ensuring you stay ahead in a rapidly evolving digital world. Choose Flexso for smart solutions and a partnership that leads to success.

Integration Content published:

Shopify Integration with SAP S/4HANA Cloud

The Shopify to SAP S/4HANA Integration Package is a comprehensive solution designed to seamlessly connect your e-commerce and ERP systems. It leverages webhooks for real-time data synchronization, enhancing operational efficiency and data accuracy.

-----------------------------------------------------------------------------------------------------------------------------------------------

Effective People A/S

At Effective People, our purpose is people. As a leading global provider of SAP SuccessFactors, HR advisory, and workforce management solutions, Effective People helps organizations across all territories and industries to drive better business outcomes, improve HR effectiveness, streamline payroll processes, and create great employee experiences. We've completed more than 1,000 SAP SuccessFactors projects in more than 100 countries worldwide throughout the past 18+ years. Our 250 consultants cover all major industries and provide continued operational support and maintenance for more than 150 companies. We're in the SAP Hall of Fame and have been awarded Expert status in SAP's Competency Framework. Together with our customers, we've won 13 SAP Quality Awards, and received the Partner Excellence Award in 2020 and 2021.

Integration Content published:

SAP SuccessFactors Employee Central Integration with SAP Concur

SAP SuccessFactors Employee Central Integration with SAP Concur enables the replication of employee data from SAP SuccessFactors Employee Central to SAP Concur.

-----------------------------------------------------------------------------------------------------------------------------------------------

NTT DATA Business Solutions AG

We understand the business of our clients and know what it takes to transform it into the future. At NTT DATA Business Solutions AG, we drive innovation for more than 30 years - from advisory and implementation to managed services and beyond; we continuously improve SAP solutions and technology to make them work for companies - and for their people.

Integration Content published:

SAP LeanIX Integration with SAP Integration Suite

This integration package is designed to synchronize data between SAP LeanIX and Integration Assessment, focusing primarily on application and vendor information. Utilizing the powerful capabilities of the SAP Integration Suite, this synchronization process ensures a seamless, secure, and up-to-date data flow. This enhances the accuracy and efficiency of IT integration strategies, providing comprehensive insights for integration assessments.

-----------------------------------------------------------------------------------------------------------------------------------------------

eMudhra Technologies Limited

eMudhra recognizes the importance of robust digital security. We're here to guide you through our specialized solutions for digital security and identity management.

API Content published:

emSigner

This package supports different signature types and ensures robust security measures, making it an ideal solution for diverse sectors. By streamlining document signing workflows, it not only automates processes but also reduces paperwork significantly.

------------------------------------------------------------------------------------------------------------------------------------------

If you are interested in Partnering with SAP Business Accelerator Hub, please refer to this section and discover center mission for more details.

Stay tuned for further updates and information by the end of the next quarter!

Workday Integration with BTP Cloud integration (BTP CI / SAP CPI) through OAuth 2.0 Authentication

2024-04-04T13:20:17.586000+02:00

Introduction:

Recently I got a requirement where BTP CI/SAP CPI should integration with workday using OAuth 2.0 authentication and replicate master data / transactional data from S/4HANA to Workday by consuming workday webservice's, since BTP CI workday adapter supports only basic authentication as a workaround solution to authenticate via OAuth 2.0.

Prerequisite:

Workday authentication details like Token URL, client ID, Client Secret, refresh token with required roles/permissions (read/write).
Check workday webservices are up and running.

I assume that you have any workday webservice to test.

Steps:

Below is the sample integration design to post cost center in workday through OAuth 2.0 authentication.

Step 1: Get Access token using Token URL, client_id, client_secret, refresh_token.

Set the header with parameter Content-Type with the value “application/x-www-form-urlencoded” and configure the connection like below to get a token.
Adding client_id and client_secret in basic user credentials of security material.
Set Body with refresh_token and grant_type

Step 2:

Once we get a token, set it in the header of type Bearer.

Step 3: Call workday web service to post data.

Hope you find this article helpful and if you have any suggestion and comments, please reply to the Comments section below.

Reference Links:

!!! Happy Learning !!!

Best regards,

Prabhugoud Gogi

Single Sign On to SAP Cloud Integration (CPI runtime) from an external Identity Provider

2024-04-11T06:53:39.270000+02:00

Introduction:

Yes, you read it right (and you read it right here !). There is an out-of-the-box approach to achieving a single sign-on (SSO) experience for user flows between a corporate identity provider (that authenticates and authorizes the user) and a tenant of Cloud Integration runtime (loosely called CPI worker) fully within the BTP ecosystem.

Ok, let’s zoom out a bit and break this down.

If you are reading this blog post, you probably know already that SAP BTP Services can leverage the OpenID Connect federation-based mechanics of SAP Cloud Identity Service (read: SAP IAS) to connect users from corporate Identity Providers like Entra ID (formerly known as Azure AD), Okta, etc. to XSUAA BTP’s OAuth Authorization Server.
This is certainly not uncharted and I did a detailed blog post a few months ago demonstrating this setup.

However, this setup applied mostly to browser-based SaaS applications (read: Design Time applications with a web frontend), and that brings us to the objective of this blog -> Customers want to put together a similar setup for their client applications that interface with SAP Cloud Integration’s IFLows (in other words, the CPI runtime).
Certainly, this is not impossible to achieve and solution blueprints like these have existed in the past:

My colleague Francisco’s blog puts API Management in between a client and Cloud Integration and enforces API Management to perform an OAuthSAMLBearer handshake.
Microsoft champion Martin Raepple teaches how to set up SAML Trust between Entra ID Identity Provider and BTP to set up a user impersonation flow.

However, these approaches were often seen as cumbersome to set up / troubleshoot and certainly not for the faint-hearted!

Solution Summary:

An easier solution can be described in two phrases: 'OpenID Connect' and 'Authorization Code grant type'. If you are super-smart then you've figured it out already. You can stop reading this blog and hack this yourself.
I wish you a nice day ahead! If you are like me and need a bit more explanation, keep reading 🙂

Here is the solution blueprint that explains that handshake:

SCENARIO: Flows that require end-user authentication from external Identity Providers can natively do so with OIDC and Authorization Code grant type

Step 0: Generate Service Instance / Service Key SAP Cloud Integration Runtime. Refer to this link. Instead of Client Credentials make sure to select Authorization Code.

Step 1: Onboard the needed corporate identity providers in SAP IAS and set up the 'Application' that connects back to your SAP BTP Subaccount as a Trusted Identity Provider via OpenID Connect. Refer to my previous blog post for a detailed procedure.

Step 2: Client (end-user) initiates a connection to the required IFlow (or API artifact). This kicks off the 3-legged OAuth user login flow.

Step 3: As the user is not signed in, she is redirected to XSUAA's login endpoint, and upon login the IAS tenant's OAuth server authorization endpoint at https://<IAS tenant name>.accounts.ondemand.com/oauth2/authorize is invoked using the authorization code grant type. The details of the actual federation as part of the handshake have been omitted here for simplicity. But suffice it to say that the authorization code from the identity provider is made available to the IAS's callback endpoint and finally made available to XSUAA's authorize endpoint and exchanged for the actual access token. This access token will bear the user's scopes and role permissions needed to access the Cloud Integration's IFlow resource.

Step 4: Once successfully authorized, on the receiver side of the IFlow, we will establish connections to 3 different types of backends for illustration purposes. a) S/4HANA Onpremise system over Cloud Connector and Principal Propagation b) SuccessFactors and c) S/4HANA Cloud with OAuth2 SAMLBearer Assertion security material.

Putting it all together:

Let's get our hands dirty by putting together the sequence now. The prerequisites to follow along are listed below:

Administrator privileges in the BTP subaccount where the Integration Suite subscription exists.
An IAS Tenant (with Administrator privileges) that can be coupled (read: Trusted) with the said BTP Subaccount.
Privileges to create Applications (read: IDP configurations) in Entra ID (Azure AD) and/or Okta.
Postman Client.
Backend systems to which the frontend user principal can be propagated to. Either of S/4HANA OnPrem, S/4HANA Cloud, or SuccessFactors tenant.

Step 0: Create a Service Instance for the Authorization Code grant type

Create an instance of the 'Process Integration Runtime' Service (integration-flow service plan) specifically with the authorization code grant type. You can copy the JSON snippet pasted below. Do not worry about the location of the redirect_uri. (When we get down to testing the flow, the browser will invoke the redirect_uri, but this has no consequence as the 'code' will be available for us to copy as a query parameter from the URL itself. When we test this from Postman the client, Postman does not invoke the URL. If you are curious to know, you can read about it here.) Also, make a note that we have specified refresh_token as part of the requested grant type. This will let us demonstrate the ability for clients to refresh the access token post-expiry.

{
    "grant-types": [
        "refresh_token",
        "authorization_code"
    ],
    "redirect-uris": [
        "http://localhost"
    ],
    "roles": [
        "ESBMessaging.send"
    ]
}

With the service instance created, generate a service key (example block is pasted below). Grab the clientid, clientsecret, authorizationurl, tokenurl attributes. We will need these later.

Step 1: Configure OpenID Connect based Trusted Identity Provider of SAP IAS in your SAP BTP subaccount

This step is the heart-and-soul of our approach. We will couple an SAP IAS tenant with our BTP subaccount that has the subscription of our SAP Cloud Integration (SAP Integration Suite) tenant using OpenID Connect protocol and then onboard the desired external Identity Providers (I will demonstrate Entra ID and Okta) as corporate identity providers in the IAS administration console.
Since I've documented the steps in my previous blog, I will not repeat the exact steps here. Please refer to the following sections in the linked blog.

Objective	Steps to follow from the linked blog
Couple your BTP subaccount and your SAP IAS tenant.	Steps 1-6
Configure applications (relying party) in Azure AD and Okta IDP based on OpenID Connect and SAP IAS as the callback URI.	Steps 7 - 25
Configure application in Okta with SAML Trust to SAP IAS.	Steps 26 - 33
Onboard the above Corporate Identity Provider configurations into SAP IAS.	Steps 34 - 46
configure IAS as the proxy Identity Provider and SAP BTP as the Service Provider.	Steps 47 - 52

Nevertheless, here is a summary of the main steps involved in the setup.

1. The subaccount where the Integration Suite subscription exists has a 'Trusted connection' with the OpenID Connect protocol (not SAML) to the IAS tenant.

2. The IAS tenant has a 'Corporate Identity provider' connection to Azure AD (Entra ID) via a set of Application credentials and OpenID Connect protocol.

3. Notice the 'Application' settings on the Azure side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment

4. The IAS tenant has a 'Corporate Identity provider' connection to Okta IDP via a set of Application credentials and OpenID Connect protocol.

5. Notice the 'Application' settings on the Okta side. The redirect URI has been set to the IAS tenant's '../oath2/callback' segment.

6. We will not leverage this flow in our demonstration but note that it is very much possible to use SAML bindings between the Corporate Identity Provider and IAS. The federation works exactly as OIDC.

7. Next, we want to demonstrate a dynamic / Group assertion / Role Collection based user role/authorization determination. For that note that on the Azure side, we have a group called 'IntegrationDevelopers' that contains the users who must be authorized to call the IFlow / API on the Cloud Integration side.

8. Notice how the 'groups' claim on the IAS side resolves to the value of the group from Azure.

9. Similarly, see that the target user has been assigned to the 'IntegrationSuiteDevelopers' Group in Okta.

10. Okta presents the user's 'Groups' claim to IAS that XSUAA will resolve in a later step.

11. As a last configuration step, notice that there is a RoleCollection on the BTP side (with the 'MessagingSend' role assigned) mapped to the respective groups from the source identity providers.

Step 2 & 3: Initiate the client flow.

The easiest way to demonstrate a client flow is to do so in Postman which natively supports simulating an OAuth 2.0 3-legged Authorization Code grant flow. We can break down the segments of the 3-legged flow in a browser as well. I will demonstrate both of these user agents.

Summary of the steps about to be performed in this section

Objective	Steps
Use Postman to set up Authorization Code flow with Okta Identity Provider	1-8
Use Postman to set up Authorization Code flow with Entra ID Identity Provider	9
Usage of Refresh Tokens	13-14
Use Browser to set up Authorization code flow with Identity Providers	15-18

1. Within the 'Authorization' tab in Postman, set the 'Type' to 'OAuth 2.0' and the 'Grant type' to 'Authorization Code'.

2. Enter the values for the Callback URL, Auth URL, Access Token URL, Client ID, Client Secret from the values saved in the Step 0 block above.

3. Click on 'Get New Access Token'. Make sure to turn on the 'Console' tab at the bottom to keep track of requests and responses across the wire.

4. Postman will launch the Logon pop-up from BTP's Authorization Server. Notice that you are presented with a list of Identity Providers to log into as configured in BTP's Trust Management section. Select the one that corresponds to your IAS Tenant.
Pay attention to the GET requests in the Console tab. You will see that the request to the 'authorize' resource is being redirected to the login page.

5. The system will prompt you to present the user identifier, this will serve as an input to the 'Conditional Authentication' block set in the IAS tenant to resolve which corporate identity provider to redirect to, for the user logon challenge.

6. The system determines that the challenge should come from Okta IDP for my *.sap.com user name. Please refer to the 'Conditional Authentication' screenshot to get a summary of the determination process.
In the 'Console' section, make a note of how the callbacks are handled.

Conditional Authentication section in SAP IAS

7. Okta will authenticate the user and present back the 'authorization code' to IAS.

8. Finally the client will exchange the authorization code for the access token from the configured token endpoint.

9. Let us now perform steps nos. 3-8 again, but this time let us log in with our *.outlook.com user that gets authenticated and authorized from Entra ID (Azure AD).

10. Upon inspection, you will note that the access token issued by XSUAA has the 'ESBMessaging.send' scope as determined by the 'Groups' claim presented by the source IDP. You will remember that we created a mapping for this resolution in a previous step. Also, note that the system bears a refresh_token.

11. Further, if you inspect the respective JWTs issued by Okta and Entra ID, you will see that the tokens contain the claims that represent the Groups, RoleCollections, and User Identifier info.

12. Simply go ahead and 'Use Token' to load the token to make your request.

13. Using the refresh_token -> Notice that the token will expire after a set duration (based on the 'expiry' setting). As you can see in the screenshot below, Postman detects that the available token is expired. It gives an option to 'Refresh' the token. Click on this button.

14. Make a note in the Console tab that the client POSTs to the token endpoint with the available refresh_token and the refresh_token grant_type to get a fresh access token.

15. In the next screenshots, let us perform the same set of steps in a browser. We will need to frame the URL to the /oauth/authorize endpoint. The easiest way to do so would be to copy the URL from the Postman Console we referred to before. The URL is in the format :

https://<tenant-id>>/authentiation.<dc>.hana.ondemand.com/oauth/authorize?
response_type=code&client_id=<url-encoded-client-id>&redirect_uri=<url-encoded_redirect_uri>

16. Invoke the URL in a browser.

17. After the 'login' and 'authenticate' procedures, you will see that the browser is redirected to the redirect_uri location. You can copy the 'code' parameter from the URL.

18. Go back to Postman and POST the Access Token endpoint with the grant_type set to authorization_code and the copied code and the redirect_uri. The server will respond with the access_token with the same set of attributes populated as demonstrated in Step 11.

Step 4: Integration Flow Reciever side propagation

Now that we have an access_token that can be presented to the Cloud Integration runtime (to a 'Sender Adapter'), let us put together a simple IFlow that can demonstrate the fact that the user's identity from the external identity provider can be propagated to 3 backend systems - a) S/4HANA Onpremse, b) SuccessFactors and c) S/4HANA Cloud via Principal Propagation and OAuth2SAMLBearer mechanisms respectively.

Here is a summary of the steps we intend to achieve:

Objective	Steps
Create a sample IFlow that demonstrates the user propagation sequence to 3 different types of backend systems.	1-2
Invoke S4HANA Cloud backend	3 - 7
Invoke SAP SuccessFactors backend	8 - 13
Invoke SAP S/4HANA Onpremise backend	14 - 17

1. Let's start by putting together a simple IFlow to illustrate the user propagation flow. Since we are planning to invoke with 3 backends, the quickest way to demonstrate this would be to create a Router that has 3 branches. Each with a 'Request-Reply' step for the backend type, S/4HANA Cloud, SuccessFactors, and S/4HANA OnPremise respectively.

2. The logic we will follow is that the client passes a value in a custom header named 'target' that shall determine which of the routes is to be invoked.

3. In the property sheet of the HTTP Receiver for S/4HANA Cloud backend, notice that we've used a credential named 's4hanaCloudCredentials' with the OAuth2 SAML Bearer Assertion type.

4. I will not get into the details behind how the attributes of this Security Material have been formulated. Refer to parts of this blog post for details. The points worth mentioning here are that a) we are using the target system type SAP BTP (CF) and b) the 'userIdSource' attribute is annotated for 'email' & nameIdFormat is set to 'urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress', thereby implying that the user identifier from our original JWT token negotiated with the corporate identity provider will serve as the user principal to be propagated.

5. Let us make a call to the IFlow URL with the access token set from step 8 described in the above section. Note that we've set the 'target' header attribute to 's4hanacloud' so that the call gets executed in the first route. We get an HTTP 200 OK and the service document as the response and there you have it! We were able to successfully propagate the user from an external identity provider and execute a call in an S/4HANA backend with the user's context.

6. How do I prove my point that the user was indeed propagated? The next two screenshots do so. Note that on the S/4HANA side, I have a 'Business User' that bears my (that is propagated from Okta) emailID. Also, note that the HTTP Call is executed with this user context and NOT with a Communication User (technical user) attached to the Communication Arrangement.

7. Further to prove my point, I execute step no. 5, this time by presenting my *@outlook.com user (that comes from Entra ID), you see that the call fails and the error description calls out that the backend was not able to resolve the presented *.outlook.com user.

8. Let us now look at the 2nd route, the one that invokes a SuccessFactors URL. We extend the same 'OAuthSAMLBearer Assertion' type with a credential named 'SFSFUserPrincipal'. On the processing tab, you will see that I'm invoking a GET Query on the JobProfile resource.

9. In the details of the Security Material, note that we've set the attributes per SuccessFactors documentation. The User ID is set for principal propagation. Like before, we've used the same nameIdFormat as set in step 4 above, and don't forget to include the apiKey attribute as well.

10. Let us now invoke the IFlow, this time around with the header 'target' set to 'sfsf'. I get back a response from SuccessFactors with the JobProfile details.

11. Again, how do we prove that the call indeed was made in the signed-in user's context? There are many ways to establish this. A simple way I followed was to put a 'proxy' layer like API Management before the call hits the SuccessFactors backend and print out the 'Bearer token' from the 'Authorization' header. Upon Base64 decoding the token, you will see that the token bears a 'sfPrinciple' attribute with the employee ID identifier.

12. Look up the employee profile of the user in question in your SuccessFactors tenant and you can verify the matching employee ID and the corresponding email address.

13. Negative testing -> If I perform the call again, this time by signing in with the email address from Entra ID you should see a 401 unauthorized exception stating that the propagated user wasn't resolved.

14. Finally, we are down to the last segment of our testing. A connection to S/4HANA On-premise. I've configured an SAP Cloud Connector and an X.509 certificate signing procedure (that is beyond the scope of this demonstration) and have dialed 'Principal Propagation' for the authentication type.

15. Invoking the client this time around with the 'target' header set to 's4hanaonpremise'. I get back a response from the server with my service document for the invoked GWSAMPLE_BASIC OData service.

16. As a quick verification step, let us go to the 'Monitor' section in the Cloud Connector and within the 'Most Recent Requests' tab, you can see a record for the 'User' that was propagated.

17. Open the LJSTrace log file and you can hunt down a log entry that corresponds to the user subject that was propagated via the short-lived x.509 certificate.

Phew!

Summary:

It is beyond doubt that 'client credentials' and 'x.509 certificate' are the two most prominent and widely popular ways to authenticate to an Integration Flow / API artifact in SAP Integration Suite, but should you have a requirement to authenticate and authorize with the client user's identity from a corporate Identity Provider, OpenID Connect support from SAP Cloud Identity Service along with the Authorization Code grant type in SAP Integration Suite provide an excellent and out-of-box approach to get your job done.

Cheers, and more power to the SAP Integration Suite Community!

SAP Cloud Integration: Understanding the XML Digital Signature Standard

2024-04-15T10:23:50.369000+02:00

SAP Cloud Integration offers iFlow steps for signing and verifying XML content according to the "XML Signature" standard. This standard provides some benefits and flexibility specifically for xml content.
The present article is intended to introduce into the "XML Signature" standard, as preparation for hands-on tutorial in next blog post.
I'm trying to explain everything simple, with my simple understanding and my simple words - this is not a professional article.
In this blog post, I will try to answer many questions and show examples.
The following concepts are explained:
Hash/Digest, Digital Signature , XML Signature.
The next blog post shows how we can sign/ verify XML payloads, according to the XML Signature spec, manually in a Groovy script.

Overview

History
Basics: Digest, Digital Signature
Specifics: XML Signature
Canonicalization
General Info

1. History

How I imagine that everything started:
Timmy from Texas wanted to share some secret info with his friend Taku in Tokyo.
So he encrypted a message and sent it to Taku.
Taku was unable to decrypt and read the message.
So Timmy travelled to Tokyo to enjoy some food and to explain the way how he encrypts and packages his messages.
Afterwards, Taku in Tokyo was able to decrypt and read all messages (even before breakfast).
Some time later, same situation happened with his friend Toto in Togo.
Although the food is said to be great, Timmy decided not to travel, but to invite his friends for a conference at home.
They had international food, late-night discussions and at the end, they agreed on a common way of sending secure messages.
As a consequence, everybody in the world can send secure messages and the recipients can understand the message, as long as they follow that agreement.

Does that make sense?
Really makes sense, especially the section about the international food (which didn’t make it into the specification).

What do we learn from this story?
People communicating with each other need to agree on some basic principles:
- how encryption is done, which steps in which order
- what exactly is encrypted
- which algorithms are used
- certificate information
- where is that information stored

This intro was copied from my cms-post.

2. Introduction to Digital Signatures

We start from the very beginning to explain the concepts of signing.
Experienced readers can skip this section.
Can we skip the blog post?
Experienced readers can skip the whole blog post.

Example:
You want to buy something, e.g. a cat 🐈
You take a piece of paper, write a contract which covers the product and the price, go to post office and send it to the dealer.
The dealer calls you and says that your request is not valid.
Ohhh- What has happened?
The dealer doesn’t trust a contract that is not signed.

OK.
Try again: this time you sign the contract with your signature. ✍️
You receive a package…
Exciting…
… but it contains a hungry crocodile instead of a fluffy cat, plus the price is much higher.
OMG - What has happened? 🐊
Somebody modified the contract replacing animal and price.

OK.
Try again: this time you sign the contract, put it in an envelope which you close with a seal. ✉️
Afterwards, you finally receive your fluffy cat (a bit fat, though). 😺
Cool 👍What has happened?
The dealer trusts the signature and moreover, the contract couldn’t be altered, as it was secured.

What do we learn?
We need two mechanisms to ensure:
🔹 The content is not modified ➡️ “integrity”
🔹 The content is original ➡️ “authenticity”.

Nice. Ehm - why do we have to learn that?
Now let’s transfer this learning to the digital world.

How do we ensure integrity in a digital world?
Let's see a common example where integrity is required:
Downloading software from a web page.
Usually, in addition to the zip file, a checksum is published in the website.
This allows us to verify that the zip is not modified.
So we’re sure that there’s nothing malicious in it (allowing a hacker to e.g. steal our private cat photos)

What is a checksum?
In general, it is the same as: “hash” or “hash value” or “hash code” or “digest” or “fingerprint”.
Ehhmmm - what?😕
It is a code, a silly combination of characters and numbers.
Can we have an example?
This is a hash code:
f7a5f85f2b80792a7b4650f009b130dd1b955d855c99ef64d7b98e5f103f3709
And this is a digest:
f7a5f85f2b80792a7b4650f009b130dd1b955d855c99ef64d7b98e5f103f3709
It is the same... 🤔
Exactly.

How does it work?
To produce a hash code, we need to use a hash function, or better a cryptographic hash function (CHF).
What’s the difference?
Generally speaking, CHF is more secure.
Differences are fine-granular and security related.

What is a hash function?
Based on an algorithm, the hash function creates a hash code from any input data (e.g. text, image, etc).
Important properties:
- The input can be of any size, where the digest will always have a fix size.
- It is not possible to guess the original text from the digest (one-way).
- Any small change in the input file will produce different digest (hash collision).
- As such, the digest (hash) proves that the original input is not changed (-> integrity).
BTW, no key or secret or password is required here

Any examples for hash functions?
SHA-256 (and more), MD5 (and more), RIPEMD, BLAKE (etc), GOST

What are the differences?
Some are more safe than others

What does SHA-256 mean?
It stands for "Secure Hash Algorithm" and the hash value has a size of 256 bits.
See below for more info.

Now a diagram would be helpful...
OK OK

How is a cat function used?
You mean hash function.
We have an important document that should be signed.
We create a hash value with a (cryptographic) hash function (e.g. SHA-256).
We send both to the receiver.
The receiver views the document and wonders if it might have been altered.
He creates his own hash value with same hash algorithm (SHA-256).
He compares his own hash value with our value which we had sent to him.
As we know, even the slightest change in the document results in a different digest.
If both hashes are equal, he can be sure that the content was not altered.

Can we look at a dia…
OK OK

Nice. Can we try it out?
Yes. See next blog post

So the Signer in CPI is a hash function?
No.
What is it? A fat cat?
No, we have to go one more preparation step further.
Simply using hash is not secure enough.
Super, I’ve wasted my time ;-(
Wait.
A malicious hacker who intercepts the e.g. eMail can alter the document, create his own new hash and forward the eMail. Nobody would notice that the document was changed.
So the weak point is: we don’t have authenticity.
To overcome this weakness:
Use digital signature.

What is a digital signature?
In brief: create a hash value and then encrypt it.
In long?
Similar as before, we create a hash value to ensure integrity.
Now we want to protect the hash.
To avoid hacker attacks, we encrypt the hash with a private key.
(As prerequisite, we need a key pair.)
Then send the document along with the encrypted hash to the receiver.
(The receiver needs our public key. The public key is public, so there’s no problem with it.)
The receiver can decrypt the encrypted hash with the public key.
Then he can proceed as explained before:
create his own hash and compare..
Why is this more secure?
It is impossible for a hacker to decrypt the hash, to alter the doc and create new hash.
If the hacker alters the doc, creates a new hash and encrypts it himself (with his own private key), then the receiver won’t be able to decrypt with public key.
This would mean that the doc was hacked.

Oh, that sounds complex….
OKOK, here comes the visualization:

What about the keys?

In asymmetric encryption, we always talk about key pairs.
Private and public key are always generated together, they mathematically belong together.
The public key is public and can be published in the internet.
It is not possible to guess the private key from it
To generate a key pair, we use tools, like openSSL, or CPI, etc.
What about the practical example?
<Sigh>. See next blog post

So the Signer in CPI is a digital signature?
Almost.
Why?
We have to go one last education step further:
The signer in CPI is embedded into the XML Signature standard.
Now comes the next question,,,

What is XML Signature Standard??
It is not only a normal signature, it is more than that.
We’re signing a message and sending it out to a receiver.
To enable the receiver to decrypt/verify it, we need to add additional information/metadata to the message (e.g. algorithm info).
All must be nicely structured, as the receiver needs to know where to find everything he needs to decrypt and verify.

Is there anything else?
Yes...
OMG - don't want to know it...
The difference between XML Signature Standard and CMS (PKCS7) Standard:
The CMS Standard can be applied to sign any content, including xml, no problem.
However, the XML content itself is structured – so why not use the structure to add the signature-metadata-structure to it?
Furthermore, there’s a big advantage in having structured XML content:
Instead of always signing the content as a whole, we can choose to sign only an XML subtree.

Why is this an advantage?
The message content might contain a section containing info that does change, but doesn’t affect the integrity.
For example: a timestamp
We don’t want a changed timestamp to cause the signature-verification to fail.

Is there a disadvantage?
Yes
I don’t want to know it (I shouldn't have asked).
Sorry: we have to go through it.
Later?😸
Agreed, we talk later..

Most of this intro was copied from my CMS Signer blog post.

3. XML Signature

Up to now, we know that
🔹we have an xml content
🔹we create hash and encryption
🔹we have to store the hash and the metadata somehow in the xml.

It is time to look at the "XML Signature" standard itself.
The most important info that is defined by the standard:

What is signed?
How it is signed?
Where is it stored?

In addition:

the tedious disadvantage of xml

So let’s get to know it.
Our examples are based on this simple sample xml service payload:

3.1. Signing Modes

As mentioned, xml allows for flexibility:
A signature can be enveloped or enveloping.

Sounds confusing. What does it mean?
Personally, I translate it as follows:

Enveloping = embracing = parent
Parent embraces a child.
If a signature is enveloping, this means:
The signature is a parent node of the whole content.
With other words: our message is a child node of a new signature-root node.

Enveloped = embraced = child
The signature is a child node of the message content.
The xml content is enriched with an additional <Signature>-section:

And finally, there’s an additional variant:
Detached
In this case, the signature is a standalone xml tree which lives somewhere next to the xml content.
Like so:

Understood?
ehhmm....
OK, let's repeat with more detailed pictures
Can we play a game?
Sigh 🙄
What kind of signature mode is applied below?

Umm - enveloped?
Great.
And here?

Umm - enveloping?
Perfect.
Is there a price?
What do you want?
Ummm - a croco...?

3.2. Structure

The examples above have been very simplified, let’s have a closer look now.
When calculating the XML Signature of an XML content, then we get a result which itself is an XML tree.
The root element of this tree is a <Signature>.
Roughly speaking, this tree has the following 3 main sections:

<Signature>
    <SignedInfo>
    <SignatureValue>
    <KeyInfo>

Explanation of <Signature> section:

<🔸><SignedInfo>
This top-element contains the information and metadata that are considered during signing.
Personally, I don’t like the name, it is somehow confusing.
I would prefer to call it “Info about Signing”

<🔸><SignatureValue>
The overall result of the signing process is contained here.
Note that the result has to be encoded with Base64, before it can be inserted in an XML payload.

<🔸><KeyInfo>
This element can contain the public key, which is required to verify the signature.
Instead of the public key itself, the certificate (or parts of it) can be included.
This element is optional. The required public key can be already known to the receiver.

More details:

Explanation of <SignedInfo> section:

<🔸><CanonicalizationMethod>
This element contains the info about which canonicalization method is applied to the content, before signing.
See chapter below for more info.
Example:
http://www.w3.org/2006/12/xml-c14n11

<🔸><SignatureMethod>
The algorithms used to digest and encrypt, during signature creation.
For instance, use a SHA algorithm with key length 256 to create the hash value, then use an RSA based private key to encrypt the hash.
Example value:
http://www.w3.org/2001/04/xmldsig-more#rsa-sha256

<🔸><Reference>
We have to store the information about what content is signed.
As we know, it can be the whole content or just any xml-element somewhere in the tree, or even outside.
As such, it is necessary to point to the xml-element that is signed.
That’s done via the <Reference> tag which contains an URI attribute.
So the <Reference> stands for the content to be signed.
There can be multiple separate xml-sections specified by multiple <Reference> nodes.
Furthermore, the <Reference> contains the information, how the content is treated.
Such info is contained as <Transform> element

<🔸><Transforms>
There can be multiple transformations that are applied to the selected content, before signing.
One prominent example is the canonicalization.

<🔸><DigestMethod>
This element is a child of the <Reference>.
As such it is relevant only for the content which is specified by the <Reference>.
Here we can see which hash algorithm is applied to the content.
Example:
http://www.w3.org/2001/04/xmlenc#sha256

Note that his URI points to the xmlenc ("XML Encryption") standard which defines the usage of the SHA-256 algorithm. Same is valid here.

Note that in XML Signature, there are 2 separate hashing steps, that’s why we have 2 elements containing info about hash-algorithm.
See below chapter for more explanation.

<🔸><DigestValue>
Again, this element is valid for the specific <Reference> only.
The hash of the referenced content is calculated with algorithm mentioned above (SHA-256).
The result is stored here.

<🔸><...>
There are a few more elements, but let’s ignore them here.

Example for <Signature> structure:

Example with values:

3.3. Process

To better understand what is happening, we should have a look at what is actually done, when creating an xml signature - and when verifying it.

3.3.1. Process of Signing

We learned above:
A digital signature means to create a hash and encrypt it.
Um?
No nooooooo...
Unfortunately, the XML Signature Standard is not so simple.
We’re not just creating a signature of some content.
To make it secure, even the metadata and the hash need to be signed.
Sigh ;-(
OK. Let's...
Yes, sign makes me sigh…..
OK.
And makes me sick….
Let’s get a rough overview of the overall process.

1. The content:
These steps are done with the content, .e.g the message payload.

1.1. The content that should be signed is identified.
Example:

1.2. This content is canonicalized.
1.3. The digest of the content is calculated.
1.4. The digest is base64-encoded.

2. The <SignedInfo>
These steps are done with the <SignedInfo> element.

2.1. The <SignedInfo> element is constructed.
2.2. The calculated digest (see 1.3.) is inserted in the subtree.
2.3. The <SignedInfo> element is canonicalized.
2.4. The signature of <SignedInfo> element is created.
2.4.1. The hash of <SignedInfo> is calculated
2.4.2. The hash is encrypted with private RSA key
2.5. The signature is base64-encoded

3. The whole Document
Finally, the overall message payload is affected.

3.1. The final result, the whole <Signature> element is constructed.
3.2. The signature (see 2.4.) is inserted
3.3. The super-final result, the documents as a whole, is enriched with the <Signature> element.

Summary
The content is digested.
The <SignedInfo> is digested and signed.
In addition: beforehand the canonicalization – and afterwards the base64-encoding has to be applied.

The simplified result of an enveloped signature:

3.3.2. Process of Verification

Let’s briefly repeat the process, this time from the verification perspective.

Ehmm - what does verification mean?
Repeat:
🔷Verification of a digest:
-> compute a new hash
-> then compare it to the original hash.

🔷Verification of digital signature:
Decrypt
-> Decrypt the signature with public key
-> compute a new hash
-> then compare it to the original hash.

🔷Verification of an XML Signature:
See below.

1. Verify the content-digest

Here, we're talking about the hash that was calculated of the original message payload (or part).

1.1. Identify the content (info found in <Reference>).
1.2. Apply the canonicalization and other transforms (info found in <Reference>).
1.3. Identify the algorithm for hashing (info found in <Reference>/<DigestMethod>).
1.4. Calculate new digest.
1.5. Identify the old digest from <Reference>/<DigestValue>.
1.6. Compare both.

2. Verify the signature

Here we're talking about the <SignedInfo> element, which was signed.
To verify a digital signature, a public key is required, which is either known or contained in the xml.

2.1. Identify the <SignedInfo> element.
2.2. Identify the method for canonicalization (info at <SignedInfo>/<CanonicalizationMethod>)
2.3. Canonicalized the <SignedInfo>.
2.4. Fetch the public key, which is either known, or contained in <Signature>/<KeyInfo> element.
2.5. Identify the algorithm (info in <SignatureMethod>)
2.6. Perform the signature-verification

4. Canonicalization

Finally, let's talk about that tedious topic, as I promised above.
Can we do that later...?

4.1. Intro

OK.
What is canonicalization?
We know that XML is used for storing structured data and for enriching it with metadata.
Example:

<order>
   <customer trusted="yes" active="true">Joe</customer>
</order>

When reading the data from it, we don’t care about the way how it is formatted:

<order    >
   <customer 
         active="true" 
         trusted = ’yes’>
      Joe
   </customer>
</order   >

Both XML snippets are valid and have the same content - although they look different.
We don’t care about
🔹silly spaces
🔹useless line feeds
🔹using inverted comma or quotation marks
🔹using different order of attributes
Etc
Sure - I don't care at all 😹
However……
In case of cryptographic hashes, we know that changing one little cute byte does invalidate the content and causes the verification to fail.
So just imagine that the xml payload goes through an iFlow……. It will be for sure re-formatted by any iFlow step. Normally, this doesn’t matter, because xml is anyways parsed by machines, so the format is irrelevant.
But if some xml is used for signature, then the format matters.
Really?
Really really matters ❗

How can it be solved?
We must agree on a totally default standard format for xml.
This must be agreed on – which results in another standard.
OMG - how boring 😴
And here it is:
The XML Canonicalization standard.
Applying canonicalization to both sample snippets above, would result in a third representation:

<order>
   <customer active="true" trusted="yes">Joe</customer>
</order>

We can see that the attributes have fix order, useless spaces have been removed, etc
What does the spec say?
Let’s have a look at the spec and copy a little excerpt:

🔹 The XML declaration and document type declaration are removed.
🔹 Attribute value delimiters are set to quotation marks (double quotes).
🔹 Empty elements are converted to start-end tag pairs.
etc

Why do we need different canonicalization methods?
Good question and I recommend the tutorial for visual understanding.
🔹There are small differences in the different versions of specs.
🔹Also, we can choose if we want to keep comments or not.
🔹And one important difference is the exclusive canonicalization (specified here)

Last question: c14n?
The word canonicalization is so long and hard to type and pronounce… people like to use c14n as abbreviation.
The number 14 stands for the number of characters between c and n.
Haha

4.2. Optional: C14N Tutorial

You imagine how much I enjoyed typing C14N instead of Canoni….
Let’s have a look at a few examples to see how c14n works.
I’ve prepared a little code sample which uses the Apache Santuario library for c14n.
The full code can be found in the Appendix.

xample 1: Simplest xml with Comment

Our first sample XML:

<!-- my comment -->
<parent    >
   <child    batt='yes'    att='no'    />
</parent   >

We apply this c14 method: http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments

We use this Java code:

Canonicalizer canon = Canonicalizer.getInstance(c14nMethod);
canon.canonicalize(xml.getBytes(), System.out, false);

And the result:

<!-- my comment -->
<parent>
<child att="no" batt="yes">
</child>
</parent>

What we see:
🔸The comment has been preserved
🔸The blanks inside the <parent > tag have been removed
🔸The attributes have been ordered (a comes before b)
🔸The inverted commas have been adapted

Example 2: Simplest xml removing Comment

Now we use the same input, but apply the c14 algorithm which removes comments:
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

The result is the same as above, but without the comment in the first line.

Example 3: Namespaces and subtree

An interesting aspect is the propagation of namespaces.
This becomes relevant, when we create a signature of a subtree only.
In this case, the child element inherits the namespaces declared at parent.

In the following examples we will apply the c14n on a child node only.
The XML content has a root element with 3 child elements.
The parent has 2 namespace declarations.
The children use only 1 of the declared namespaces.

<parent 
      xmlns:pans='/pauri' 
      xmlns:chns='/churi'>
   <child chns:att='good'/>
   <friend pans:att='OK' chns:att='cool'/>
   <brother/>
</parent>

We apply the c14n method on the element “child”
http://www.w3.org/TR/2001/REC-xml-c14n-20010315

The sample code uses DOM method for retrieving the desired child node.
Note that in the context of XML Signature it is recommended to use xPath, not DOM.

InputStream stream = new ByteArrayInputStream(xml.getBytes(StandardCharsets.UTF_8));
Document doc = XMLUtils.read(stream, true);
Node myChild = (Node)doc.getElementsByTagName(element).item(0);

Canonicalizer canon = Canonicalizer.getInstance(c14nMethod); 
canon.canonicalizeSubtree(myChild, System.out);

The result:

<child xmlns:chns="/churi" xmlns:pans="/pauri" chns:att="good"></child>

We can see that both namespace declarations have been propagated to the child by the canonicalizer.

Example 4: Exclusive Canonicalization

To understand what "exclusive" means, we run the same example, but applying the exclusive method:
http://www.w3.org/2001/10/xml-exc-c14n#

The result:

<child xmlns:chns="/churi" chns:att="good"></child>

We can see that only the one required namespace declaration has been propagated.

Example 5: Exclusive Canonicalization 2

Now let's compare to the <friend> element which has 2 attributes using both namespaces.
The result:

<friend xmlns:chns="/churi" xmlns:pans="/pauri" chns:att="cool" pans:att="OK"></friend>

We can see that both declarations have been propagated from the parent.

BTW, we can also see that the declarations and attributes are nicely ordered.

Example 5: Exclusive Canonicalization 3

Last example: we apply c14n on a child node that doesn’t have any attributes, hence doesn’t use any namespace.
As a result of applying the exclusive canonicalization method, we can see that none of the declarations has been propagated:

<brother></brother>

Next test would be:
Use the normal c14n method, not exclusive.
We would wee that all declarations are inherited. Without necessity.
We skip it here, but it is contained in the Appendix.

BTW, furthermore we can see that the shortcut for empty tags has been replaced:

5. Optional: Some General Info

There are several different names for the same thing:
🔹XML Signature is the official name, as used in the specification.
🔹It is also called XMLDSig, XML-DSig, XML-Sig.
🔹Personally, I would like to add the names XML-Digi-Sigi and xml-disi to the list (but up to now, nobody has adapted).

The standard was developed by the World Wide Web Consortium (W3C) and published as a W3C Recommendation.
The specification can be found at https://www.w3.org/TR/xmldsig-core/

It has version 1.1 as of 2013, which is expressed in the internal link http://www.w3.org/TR/2013/REC-xmldsig-core1-20130411/

REC stands for recommendation, this is the mature result of the definition process.
TR stands for Technical Report, this is a general hint towards the character of the standard+

The XML Signature is used in xml-based technologies like SAML, SOAP, WSSecurity.

Summary

The XML Signature standard is used for creating a digital signature of xml content.
The signature is represented by an xml-tree
The standard defines

🔷 3 ways of signing xml content: enveloping, enveloped and detached.
- The signature can be inserted as subtree somewhere in the xml content (enveloped).
- Or the signature xml tree can contain the content as a subtree (enveloping).
- Alternatively, the Signature xml tree can be detached from the content and live as standalone xml.

🔷 a process of creating a hash of the desired content and in addition creating a signature over a part of the signature itself.

🔷 an xml structure for storing the signature and digest, that are required for verification.

Next Steps

Go through the tutorial in the next blog post to gain hands-on experience.

Links

SAP Help Portal
Docu for Message-Level Security

Specs
XML Signature: https://www.w3.org/TR/xmldsig-core/
C14n Version 1.1 https://www.w3.org/TR/xml-c14n/
C14N Version 2 (2013) https://www.w3.org/TR/xml-c14n2/
Exclusive c14n Vers 1 https://www.w3.org/TR/xml-exc-c14n/

Info
Wikipedia: CHF, Cryptographic Hash Function
Wikipedia: Comparison of cryptographic hash functions
Wikipedia: Digital Signature

Libs
Apache Santuario implements XML Enc and DigiSigi standards.

Blogs
Understanding the XML Encryption standard.
Understanding CMS (PKCS 7) standard.
Understanding the PKCS7/CMS Signer
Security Glossary Blog

Appendix: C14N Test Code

To get below code working, the Apache Santuario library is required.
It can be downloaded from here: https://mvnrepository.com/artifact/org.apache.santuario/xmlsec
Alternatively, below snippet can be added to your Maven dependencies section:

<dependency>
   <groupId>org.apache.santuario</groupId>
   <artifactId>xmlsec</artifactId>
   <version>4.0.2</version>
</dependency>

This test class is for your convenience:

package example.c14n;

import java.io.ByteArrayInputStream;
import java.io.InputStream;
import java.nio.charset.StandardCharsets;

import org.apache.xml.security.c14n.Canonicalizer;
import org.apache.xml.security.utils.XMLUtils;
import org.w3c.dom.Document;
import org.w3c.dom.Node;

/** Using Apache Santuario library for canonicalizing different XML payloads */
public class CanonTest {

	
	public static void main(String unused[]) throws Exception {
		org.apache.xml.security.Init.init(); 
		
		// example for handling comment and basics
		String xmlSimple = ""
				+ "<!-- my comment -->"
				+ "<parent    >"
				+     "<child batt='yes' att='no'    />"
				+ "</parent>";
		
		// apply different canonicalization methods 
		canoFull(xmlSimple, Canonicalizer.ALGO_ID_C14N_WITH_COMMENTS);
		canoFull(xmlSimple, Canonicalizer.ALGO_ID_C14N_OMIT_COMMENTS);

		
		// example for handling namespaces
		String xmlWithNs = ""
				+ "<parent "
				+       "xmlns:pans='/pauri' "
				+       "xmlns:chns='/churi'>"
				+     "<child chns:att='good'/>"
				+     "<friend pans:att='OK' chns:att='cool' />"
				+     "<brother/>"
				+ "</parent>";
		
		// apply different canonicalization methods on different subtrees
		canoSubtree(xmlWithNs, "child", Canonicalizer.ALGO_ID_C14N_OMIT_COMMENTS);
		canoSubtree(xmlWithNs, "child", Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);
		canoSubtree(xmlWithNs, "friend", Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);
		canoSubtree(xmlWithNs, "brother", Canonicalizer.ALGO_ID_C14N_OMIT_COMMENTS);
		canoSubtree(xmlWithNs, "brother", Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS);
	}

	private static void canoFull(String xml, String c14nMethod) throws Exception {
		System.out.println("\n\n- - - " + c14nMethod + " - - - \n");

		Canonicalizer canon = Canonicalizer.getInstance(c14nMethod); 
		canon.canonicalize(xml.getBytes(), System.out, false);		
	}	
	
	private static void canoSubtree(String xml, String element, String c14nMethod) throws Exception {
		System.out.println("\n\n- - - " + c14nMethod + " - - - \n");

		InputStream stream = new ByteArrayInputStream(xml.getBytes(StandardCharsets.UTF_8));
		Document doc = XMLUtils.read(stream, true);
        Node myChild = (Node)doc.getElementsByTagName(element).item(0);

		Canonicalizer canon = Canonicalizer.getInstance(c14nMethod);//Canonicalizer.ALGO_ID_C14N_EXCL_OMIT_COMMENTS 
		canon.canonicalizeSubtree(myChild, System.out);			
	}	
}

Cloud Integration: Manually Sign / Verify XML payload based on XML Signature Standard

2024-04-16T10:48:33.918000+02:00

SAP Cloud Integration offers iFlow steps for signing and verifying XML content according to the "XML Signature" standard. Nevertheless, there are use cases that require configurations that are not supported by the iFlow steps. Fortunately, in such cases we still can use Groovy scripts for manually sign or verify message payloads according to the requirements.
This blog post provides an entry point for creating Groovy scripts for signature creation and verification, based on the “XML Signature” standard.
This standard provides some benefits and flexibility specifically for xml content and was explained in my previous blog post.
This blog post covers
🔸 SAP Cloud Integration on Cloud Foundry
🔸 Groovy / Java
🔸 org.apache.santuario library

Content

Prerequisites
Intro
1. Create Key Pair
2. Create iFlow
2.1. Create iFlow
2.2. Upload library
2.3. Groovy Script for Signing
2.4. Groovy Script for Verification
3. Run
Appendix 1: Sample XML Payload
Appendix 2: Sample Groovy Script for Signing
Appendix 3: Sample Groovy Script for Verification
Appendix 4: Maven pom file

Prerequisites

🔹CPI
To follow this tutorial, access to a Cloud Integration tenant is required, as well as basic knowledge about creating iFlows.
🔹Maven
While not required, it is an advantage to have maven installed.
🔹Understanding the "XML Signature" standard is not difficult when reading the previous blog post.
🔹For remaining open questions I recommend the Security Glossary.

Introduction

After going through the previous blog post, we’re well prepared for the hands-on tutorial in this post.

Scenario
In our Cloud Integration scenario, a sales order XML payload must be signed because it contains sensitive information (order data).
To make things easier, we hard-code the sample xml payload in the iFlow.
In a Groovy script, we sign only the subnode which contains the important info.
This is possible thanks to the “XML Signature” standard.
To prove that the new XML payload, which contains the signature part, can be verified, we add another Groovy script.
This one performs the signature verification.

Recap
The “XML Signature” standard allows to sign:
🔹The whole message (enveloping)
🔹A specific node, means the node itself plus its content (enveloped)

In our tutorial, we’re going for the second option.
The standard defines an additional XML tree that is inserted in the original document, next to the sensitive content.
This new XML tree has the root node <Signature>.

The sample payload
We’re keeping things as simple as possible, so we’re using this simple sample payload:

We want to sign the <order> node.
This ensures that neither the receiving customer nor the bought product are altered during message processing.
To be more precise:
The data might be altered, as it is not encrypted. But in that case, it would be detected, because the verification would fail.
Why we don’t encrypt it?
Because encryption is usually applied to secret content. In our example the content is not secret, as it doesn’t contain e.g. a credit card number.

Below screenshot shows the payload before and after signing:

The signing process
In the Groovy script, we’re using the Apache Santuario library, which provides an implementation of the “XML Signature” standard.
This means it is aware of the XML structure and the signing process that is defined in the standard.
It is also aware of the algorithms that are supported in the specification.

So what we have to do in the code:
🔸Compose the additional xml tree, using the objects which are offered in the library.
🔸Provide the required private key (public key optional).
🔸Choose the XML node that should be signed.
🔸Feed the signer with that node.

Note:
It is clearly recommended to use xPath for retrieving the xml node that should be verified.
The reason is that xPath helps to validate the xml structure of the whole document, as well.
However, to keep the sample code as simple as possible, I decided not to use xPath.
Please make sure to always use xPath in your productive code.

Disclaimer:
This blog post is not an official recommendation, this is not safe and not ready to be pasted into productive environment.
This is just a simplified tutorial to get everybody started.

1. Create Key Pair

There are multiple possibilities for creating a key pair.
A simple way would be to use CPI, it's fine for following this tutorial.

Ceate Key Pair in CPI

We go to keystore and choose "Create -> Key Pair"
We enter some data of your choice, e.g.
🔸Alias: “demokeypair”
🔸CN: “demokeypair”
It will be used for creating the certificate.

The alias name “demokeypair” will be used below in the Groovy scripts, in order to load the keys.

Note.
If you need examples of creating key pairs or certificate chains with OpenSSL, please refer my other blog posts.

2. Create iFlow

In this section, we’re creating a simple iFlow that does nothing but sign and verify a hard-coded xml-message.

2.1. The iFlow

Our iFlow will look as follows:

Let’s quickly go through the configuration.

🔷Timer
We define a start event via "Timer" with default properties, i.e. run once
🔷 Content Modifier
We use a "Content Modifier" in order to hard-code a dummy xml-payload in the "Message Body".
It represents an incoming HTTP request (or similar).
The content is copied from Appendix 1
🔷 Groovy Script1
The script used for signing.
The content is copied from Appendix 2
🔷 Groovy Script2
The script used for verification.
The content is copied from Appendix 3

2.2. The security library

In our Groovy code, we’re using the library Apache Santuario.
It is an implementation of the "XML Signature" standard, thus perfect for our needs.
The drawback: the library is not available in the CPI Java runtime.
We need to manually get hold of the .jar file and upload it to the iFlow.

2.2.1. Download the "xmlsec" jar file

A common place to find and download jar files is the "mavenrepository".
We find our library at https://mvnrepository.com/artifact/org.apache.santuario/xmlsec
We choose a version (in my example: 4.0.2)
We click on "bundle" to download the jar file.
in my example the file name is xmlsec-4.0.2.jar.

Alternatively: use maven as described in Appendix 4.

2.2.2. Upload

To make the jar file available for our scripts in the iFlow, we open our iFlow.
To make sure that nothing is selected, we click on the background of the designer.
At the “Integration Flow” properties, we open the tab “References”, then click on “Add -> Archive”.
We browse to our jar file and confirm the dialog.
That’s it.

2.3. The Groovy Script for Signing

Now let’s go through the code for signing xml payload according to the "XML Signature" standard.

Preparation

A brief look at the required packages:

import com.sap.it.api.ITApiFactory
import javax.xml.*
import org.w3c.*

We need some basic functionality for dealing with xml (not surprising in case of XML payload).
We cannot use native groovy xml-parsing, we need org.w3c because the apache library is based on it.
For the security related operations, we use some native Java packages:

import java.security.*
import javax.crypto.*

And finally, the protagonist, the XML Security implementation of Apache Santuario:

import org.apache.xml.security.*

Note:
I think it is definitely important to rely on a public implementation of the security standard and not to implement the single steps manually.
Reasons are the compatibility, flexibility of the standard, secure implementation, vulnerability-fixes that come with the library.

First thing we have to do is to initialize the apache library:

org.apache.xml.security.Init.init();

Key Pair

At the beginning, let’s retrieve the key pair, as both keys will be required in the script.
The key pair which is stored in the CPI keystore can be fetched using the CPI runtime API.

KeystoreService keystoreService = ITApiFactory.getService(KeystoreService.class, null) 
KeyPair keyPair  = keystoreService.getKeyPair(alias) 
return keyPair.getPrivate()

Parse xml string

Next first thing we have to do is to read the xml message and to parse it into a org.w3c.Document instance, with the help of our helper method:

Document document = convertToDocument(message.getBody(InputStream.class))

We need this document instance later.

It is our task to compose the <Signature> subtree, according to our needs and with the desired configurations.
As we know from the introduction blog post we need to specify the algorithms for signature, for digest, for canonicalization.

XMLSignature signature = new XMLSignature(doc, "", XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1)
rootElement.appendChild(signature.getElement())

Note:
The empty string parameter above is used to specify a base URI, in case that relative URLs are used in the document.
Above code places the <Signature> element below the root. We can do so, because we know that the <order> element is a child of root as well. What we want to do is to have the <Signature> subtree as sibling of the <order> node which we are signing.

The <Reference> element is composed implicitly, but we have to create the children, like <Transform> elements.

Transforms transforms = new Transforms(doc);
transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE);
transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS);

KeyInfo
The <KeyInfo> element is optional.
It allows to send the public key along with the message. This makes it easier for the receiver to verify the signature.
However, if the receiver already has the public key, then it doesn’t need to be sent.
In our example, we have the public key in the keystore, so we don’t really have to send it.
On the other side, we want to showcase how it could be done.

Note:
Instead of the public key, we could also send the certificate, which contains the public key.
This has the benefit that the metadata of the certificate could be validated by the recipient.
Another option would be to send only the serial number (or similar) of the certificate, assuming that the receiver has the certificate already and only needs to find the right one and to validate some metadata.

signature.addKeyInfo(publicKey)

addDocument

Some explanation is required with respect to the xml element which should be signed.
In the corresponding method, this element has to be specified by a String which is a URI:

signature.addDocument("#id_1", transforms, MessageDigestAlgorithm.ALGO_ID_DIGEST_SHA256);

This URI (first method parameter) can be relative (using the "#" notation) or it can point to any other xml, as specified by the XML Signature spec.
This is nice and flexible.
However, internally, it requires that the targeted element can be identified by an “ID”.
Defining an “ID” attribute for an xml element is not so simple:
We cannot just create an attribute with name “ID” or “id” or “Id”.
If we create such an attribute, it would be just a normal attribute with any name.
It has to be marked as a special “ID”-attribute.
This can be done with an XML scheme.
Or it can be done programmatically.
That’s what we’re doing in our sample, it seems the easier way.
We call our helper method:

setIdAttribute(doc, "order", "identifier")

which is implemented as follows:

def setIdAttribute(Document doc, String elementName, String idAttributeName) {
    Element orderElemToVerify = (Element)doc.getElementsByTagName(elementName).item(0);
    orderElemToVerify.setIdAttribute(idAttributeName, true);
}

Note that in your productive code this is probably not required.

Sign

Finally, the signature is created by providing the private key:

 signature.sign(privateKey)

All other configuration has been done before.

Note:
As usual, we're skipping all error handling, to make the code sample easier to read.

Output

That’s all for the signing.
At the end, we only need to convert the org.w3c.Document instance to a string and set it as message body of the iFlow.

Summary

🔹Prepare document
🔹Fetch Keys
🔹Compose <Signature> node
🔹Here: set ID attribute
🔹Sign the desired element

2.4. The Groovy Script for Verification

The verification script is much shorter because the library is in charge of finding the required elements within the XML.
We only need to take care of properly initializing the lib.

Prepare XML Document

We need to convert the XML message payload from string to org.w3c.Document:

Document document = convertToDocument(message.getBody(InputStream.class))

Again, we need to configure the attribute which we want to act as “ID”:

setIdAttribute(docToVerify, "order", "identifier")

Next, we have to get a hold of the element which represents the <Signature>, then wrap it in an XMLSignature object:

Element sigElement = (Element) docToVerify.getElementsByTagNameNS(Constants.SignatureSpecNS, "Signature").item(0)
XMLSignature verifySig = new XMLSignature(sigElement, "")

Note:
As mentioned, that code should be replaced by xPath!

For verification, we need the public key, so we fetch it from CPI keystore.
Note:
As per design, everybody should be enabled to verify a signature, that’s why the verification is done with a public key (not private key).

PublicKey publicKey = getPublicKeyFromKeystore("demokeypair")

Note:
We’re making our lives too easy, you might think, by taking the public key from keystore instead of reading it from the XML.
The answer is yes, correct.
And the reason is that I’m planning to publish another tutorial for more use cases.

Finally, do the verification:

boolean verificationResult = verifySig.checkSignatureValue(publicKey)

The verification is a simple check method that returns a Boolean.

In our simple sample, we just print the result to the console.
In productive world, the iFlow should fail, an exception should be thrown, etc

Little summary

🔹Find the <Signature> node in the XML payload
🔹Fetch the public key
🔹Configure an XMLSignature and run the check.

3. Run Scenario

At this point we’ve created a very simple iFlow with hard-coded xml-payload, signing script and verification script.
The scripts produce log output, such that we can view the message content before and after each step.

Finally, we can deploy the iFlow, I will be triggered automatically and we can view the results in the log at
Monitor -> Integrations -> Monitor Message Processing -> All Artifacts

Summary

After learning the “XML Signature” standard in the previous blog post, today we applied the learnings in java code, based on the Apache Santuario implementation of the standard.
The Santuario library knows the structure and the process of creating an “XML Signature”, we only need to collect the required information and configure the library objects:
For signing, we need:
🔹the signature mode, in our example “enveloped”
🔹the XML element to be signed
🔹the Canonicalization method
🔹the Digest alg: e.g. SHA256 (used to calculate a hash of the signed message)
🔹the Signature alg: e..g SHA256withRSA
🔹the Certificate or public key or metadata, required for verification, to be sent in the <KeyInfo> element

When it comes to verification, the library will extract all required info from the <Signature> element.
We only need to help to find it.
Also, we need to take care of the public key, which may be included in the <KeyInfo> subnode, or we have it already and may want to compare the certificate metadata.
And again (for the last time):
The XML structure as a whole should be validated as well.
Therefore, xPath should be used

Links

Specification
W3C recommendation XML Signature: https://www.w3.org/TR/xmldsig-core/

Java library
Apache Santuario

Blogs
Intro Blog : Understanding the "XML Signature" standard.
Understanding the CMS (PKCS7) Standard.
The Security Glossary.

Appendix 1: Sample XML Payload

<SalesService>
   <order identifier="id_1">
      <customer>Joe</customer>
      <product>cat</product>
   </order>
</SalesService>

Appendix 2: Sample Groovy Script for Signing

import com.sap.gateway.ip.core.customdev.util.Message
import com.sap.it.api.ITApiFactory
import com.sap.it.api.keystore.KeystoreService

import java.io.ByteArrayOutputStream
import java.io.InputStream
import java.security.KeyPair
import java.security.Key
import java.security.PrivateKey
import java.security.PublicKey
import javax.xml.parsers.DocumentBuilder
import javax.xml.parsers.DocumentBuilderFactory
import javax.xml.transform.OutputKeys
import javax.xml.transform.Transformer
import javax.xml.transform.TransformerFactory
import javax.xml.transform.dom.DOMSource
import javax.xml.transform.stream.StreamResult

import org.apache.xml.security.signature.XMLSignature
import org.apache.xml.security.transforms.Transforms
import org.apache.xml.security.utils.Constants
import org.apache.xml.security.keys.KeyInfo
import org.apache.xml.security.utils.XMLUtils

import org.w3c.dom.Document
import org.w3c.dom.Element
import org.xml.sax.InputSource


/* the main method */

def Message processData(Message message) {
    
    def signedDocument = doSign(message)
    
    def signedDocAsString = convertDocumentToString(signedDocument)
    message.setBody(signedDocAsString)
    return message
}


/* Sign */

def Document doSign(message) throws Exception {
    org.apache.xml.security.Init.init()

    PrivateKey privateKey = getPrivateKeyFromKeystore("demokeypair")
    PublicKey publicKey = getPublicKeyFromKeystore("demokeypair")   

    Document doc = convertToDocument(message.getBody(InputStream.class))
    writeToLog (doc, message, "Before signing:\n")
    Element rootElement = doc.getDocumentElement()
    rootElement.normalize()
     
    // signature object
    XMLSignature signature = new XMLSignature(doc, "", XMLSignature.ALGO_ID_SIGNATURE_RSA_SHA1)
    rootElement.appendChild(signature.getElement())
    
    // set transforms
    Transforms transforms = new Transforms(doc)
    transforms.addTransform(Transforms.TRANSFORM_ENVELOPED_SIGNATURE)
    transforms.addTransform(Transforms.TRANSFORM_C14N_EXCL_OMIT_COMMENTS)
    
    // set the element to be signed: the <order> element
    //the <order> should be signed. The FWK finds it by "id", so we have to set the "identifier" attr as id-attribute (alternatively, do with scheme)
    setIdAttribute(doc, "order", "identifier")

    signature.addDocument("#id_1", transforms, Constants.ALGO_ID_DIGEST_SHA1)  // the URI references an elem by id via this notation

    //the <KeyInfo> section contains the public key, to be used by recipient for verification
    signature.addKeyInfo(publicKey)
    
    // sign
    signature.sign(privateKey)

    writeToLog (doc, message, "After signing:\n")
    return doc
}


/* Helper */

def Document convertToDocument(InputStream stream){
   DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance()
   factory.setNamespaceAware(true)
   DocumentBuilder builder = factory.newDocumentBuilder()
   return builder.parse(new InputSource(stream))
}

def String convertDocumentToString(Document document){
    ByteArrayOutputStream outputStream = new ByteArrayOutputStream()
    XMLUtils.outputDOM(document, outputStream)
    return outputStream.toString()
}

def setIdAttribute(Document doc, String elementName, String idAttributeName) {
    Element orderElemToVerify = (Element)doc.getElementsByTagName(elementName).item(0)
    orderElemToVerify.setIdAttribute(idAttributeName, true)
}

def PrivateKey getPrivateKeyFromKeystore(alias){
    KeystoreService keystoreService = ITApiFactory.getService(KeystoreService.class, null) 
    KeyPair keyPair  = keystoreService.getKeyPair(alias) 
    return keyPair.getPrivate()    
}

def PublicKey getPublicKeyFromKeystore(alias){
    KeystoreService keystoreService = ITApiFactory.getService(KeystoreService.class, null) 
    KeyPair keyPair  = keystoreService.getKeyPair(alias) 
    return keyPair.getPublic()    
}

def writeToLog(doc, message, text){
    StringWriter stringWriter = new StringWriter()           
    Transformer transformer = TransformerFactory.newInstance().newTransformer()
    transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes")
    transformer.setOutputProperty(OutputKeys.METHOD, "xml")
    transformer.setOutputProperty(OutputKeys.INDENT, "yes")
    transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8")
    transformer.transform(new DOMSource(doc), new StreamResult(stringWriter))

    def messageLog = messageLogFactory.getMessageLog(message)
    messageLog.addAttachmentAsString("Sign", text + stringWriter.toString(), "text/plain")

    return stringWriter.toString()
}

Appendix 3: Sample Groovy Script for Verification

import com.sap.gateway.ip.core.customdev.util.Message;
import com.sap.it.api.ITApiFactory;
import com.sap.it.api.keystore.KeystoreService;

import java.io.ByteArrayOutputStream;
import java.io.InputStream
import java.security.KeyPair;
import java.security.PublicKey;
import javax.crypto.KeyGenerator;
import javax.xml.parsers.DocumentBuilder;
import javax.xml.parsers.DocumentBuilderFactory;
import javax.xml.transform.OutputKeys;
import javax.xml.transform.Transformer;
import javax.xml.transform.TransformerFactory;
import javax.xml.transform.dom.DOMSource;
import javax.xml.transform.stream.StreamResult;

import org.apache.xml.security.signature.XMLSignature;
import org.apache.xml.security.transforms.Transforms;
import org.apache.xml.security.utils.Constants;
import org.apache.xml.security.keys.KeyInfo;
import org.apache.xml.security.utils.XMLUtils

import org.w3c.dom.Document;
import org.w3c.dom.Element;
import org.xml.sax.InputSource;


/* The main method */

def Message processData(Message message) {
    
    doVerify(message)
    
    return message
}


/* Verify */

def doVerify(message) throws Exception {
    org.apache.xml.security.Init.init();

    Document docToVerify = convertToDocument(message.getBody(InputStream.class))
    writeToLog (docToVerify, message, "Before verify:\n")

    //prepare the id-attribute
    setIdAttribute(docToVerify, "order", "identifier");

 	// compose the signature object
 	Element sigElement = (Element) docToVerify.getElementsByTagNameNS(Constants.SignatureSpecNS, "Signature").item(0); // TODO replace this with xPath
    XMLSignature signature = new XMLSignature(sigElement, "");
    PublicKey publicKey = getPublicKeyFromKeystore("demokeypair")   
    
    // run the verification check
    boolean verificationResult = signature.checkSignatureValue(publicKey);
    writeToLog (null, message, "Verification Result: " + Boolean.toString(verificationResult))
}

/* Helpers */

def setIdAttribute(Document doc, String elementName, String idAttributeName) {
    Element element = (Element)doc.getElementsByTagName(elementName).item(0);
    element.setIdAttribute(idAttributeName, true);
}

def PublicKey getPublicKeyFromKeystore(alias){
    KeystoreService keystoreService = ITApiFactory.getService(KeystoreService.class, null) 
    KeyPair keyPair  = keystoreService.getKeyPair(alias) 
    return keyPair.getPublic()    
}

def Document convertToDocument(InputStream stream){
   DocumentBuilderFactory factory = DocumentBuilderFactory.newInstance();
   factory.setNamespaceAware(true);
   DocumentBuilder builder = factory.newDocumentBuilder();
   return builder.parse(new InputSource(stream));
}

def String convertDocumentToString(Document document){
    ByteArrayOutputStream outputStream = new ByteArrayOutputStream();
    XMLUtils.outputDOM(document, outputStream);
    return outputStream.toString()
}

def writeToLog(doc, message, text){
    def messageLog = messageLogFactory.getMessageLog(message)
    if(doc == null){
        messageLog.addAttachmentAsString("Verify", text, "text/plain")
        return    
    }
    
    StringWriter stringWriter = new StringWriter()           
    Transformer transformer = TransformerFactory.newInstance().newTransformer()
    transformer.setOutputProperty(OutputKeys.OMIT_XML_DECLARATION, "yes")
    transformer.setOutputProperty(OutputKeys.METHOD, "xml")
    transformer.setOutputProperty(OutputKeys.INDENT, "yes")
    transformer.setOutputProperty(OutputKeys.ENCODING, "UTF-8")
    transformer.transform(new DOMSource(doc), new StreamResult(stringWriter))

    messageLog.addAttachmentAsString("Verify", text + stringWriter.toString(), "text/plain")
}

Appendix 4: Maven pom file

Create a maven project and enter the following dependency in the dependencies section.
Note that you might need to adapt the version.
Today, the current version is 4.0.2.

<dependencies>
    <dependency>
        <groupId>org.apache.santuario</groupId>
	<artifactId>xmlsec</artifactId>
	<version>4.0.2</version>
    </dependency>
</dependencies>

Run the command
mvn package
Maven will download the dependencies to the local repository at
C:\Users\joe\.m2\repository\org\apache\santuario\xmlsec\4.0.2\xmlsec-4.0.2.jar
From here it can be uploaded to CPI.

Magic Numbers : A Solution to Foreign Characters in SAP CPI

2024-04-19T15:47:08.914000+02:00

Introduction

While using SAP CPI a consultant often faces a task of sending various types of files to an external SFTP server however more than often just simply defining the file type in the file extension is not enough. There are cases when even though we have the proper extension the file is not properly deciphered by the relevant software. Hence it becomes crucial to hardcode the encoding of the file before it is being sent to the SFTP.

Byte Order Marker (BOM) is used to define encoding and byte order in a file. Usually taking form as an encoded sequence of bytes, BOM aids software in deciphering endianness or byte order for multibyte character encodings such as UTF-16 and UTF-32. The BOMs are also sometimes referred as Magic Numbers which are specific bytes at the beginning of a file that distinguish it as a certain file type. They are also known as file signatures and can help the system identify files even without a file extension.

Advantages of using byte order marker include:

The Byte Order Mark (BOM) plays a crucial role in identifying the character encoding of a text file, especially within Unicode. Given that various encodings may coexist such as UTF-8, UTF-16 and UTF-32; the BOM distinguishes between them an operation particularly useful for those actively working with these different implications of Unicode.
The Byte Order Mark (BOM) serves as a byte order indication for encodings such as UTF-16, where the significance lies in their byte order (endianness). This specific sequence of bytes indicates whether the least significant or most significant byte precedes it.
The inclusion of Byte Order Mark (BOM) can significantly enhance compatibility, particularly in environments where diverse systems or software might interpret text files with variance; thus the use of a BOM helps guarantee that supporting programs will correctly decipher the text file.

Different types of byte order markers

Encoding	Representation (hexadecimal)	Unicode String Format
UTF-8	EF BB BF	\uFEFF
UTF-16, big-endian	FE FF	\uFFFE
UTF-16, little-endian	FF FE	\uFEFF
UTF-32, big-endian	00 00 FE FF	\u0000\u0000\uFEFF
UTF-32, little-endian	FF FE 00 00	\uFEFF\u0000\u0000
UTF-7	2B 2F 76 38 2B 2F 76 39	+/v8+/v9

A comprehensive list of all file magic numbers can be found here.

Using BOM in SAP CPI Groovy Script

Suppose we need to send a simple CSV to a SFTP which contains some Chinese characters. If we do not encode it using BOM and try opening it using excel the output will be shown as:

However when we encode it using BOM using the following code the output will be as follows:

def csvString = "Name,Age,City,ChineseText\nJohn,30,Beijing,你好世界"
csvString = "\uFEFF" + csvString; // New string after adding UTF-8 Byte Order Mark (BOM)

Hence we can see how hardcoding a byte order can help us in dealing with foreign characters and unique encoding styles.

Use of byte markers incase of bidirectional text

Certain integration which involve bidirectional texts involving a mix of both Left to Right and Right to Left directional texts this might require the use of byte markers which make it unidirectional. A good example of such kind of integrations is the Hilan interface which involves a mix of both Hebrew and English alphabets and hence viewing the data effectively becomes very difficult.

Direction	Unicode Byte Marker	Description	Preview (Showing all characters )	Final Display
LTR (Left-to-Right)	\u200E	This marker signals left-to-right text.
RTL (Right-to-Left)	\u200F	This marker signals right-to-left text.
Pop Directional Format	\u202C	The marker terminates an embedding or overrides control by popping the last direction setting.
LRE (Left-to-Right Embedding)	\u202A	This marker indicates that the following text should be treated as an embedded left-to-right block.
RLE (Right-to-Left Embedding)	\u202B	Use this marker to indicate that the following text should be treated as a right-to-left block.
Left-to-Right Override	\u202D	This marker enforces left-to-right direction for the enclosed text, overriding the default right-to-left direction.
Right-to-Left Override	\u202E	This marker enforces right-to-left direction for the enclosed text, overriding the default left-to-right direction.

Conclusion

While the use of BOM can be beneficial in certain situations, it is not always required or preferred. In some instances, such as HTTP responses and scripting languages, including BOMs can cause unforeseen issues. Therefore, it is crucial to evaluate the specific requirements and compatibility of the systems and tools being utilized before deciding to incorporate a BOM in text files. BOM should also be carefully used incase of fixed width files as it introduces additional special characters which might cause an issue with the interpreting software.

FAQ for C4C Certificate Renewal

2024-04-23T18:12:24.183000+02:00

SAP Passport CA G2

Renewal of SAP Passport CA G2 certificate common questions:

What is expiring on 14th May 2024 and what will be impacted?

The Intermediate Certificate of the M-user, which is SAP Passport CA G2 validity, expires on 14th May 2024.

There is no change on the root and leaf certificates, if you’ve done certificate pinning in any of your integrations/environments using the subject then there is no change or impact as it will work as usual, but the intermediate certificate of that chain is being renewed. Hence, it is mandatory to add the new certificate (SAP Passport CA G2) to your trust list so that your integrations will not break.

Download the new certificate from the KBA #3402581

M-user certificate has a validity of more than the expiry date of the Intermediate Certificate (SAP Passport CA G2) will this have any impact on our integration?

There will be no impact on your existing M-user certificate, you can still use it till the expiry, but you need to add the new certificate (SAP Passport CA G2) to your server integration trust list, whereas from the C4C side, the trust store is already added with the new certificate.

We have no direct connection- All our connections are routed through CPI. Do we need to update to update the certificates in Production in this case?

If your productive tenant is routed through Load Balancer and not Akamai, you need to consider updating the Intermediate certificate into CPI Key Store.

The SAP Passport CA G2 is already renewed, so you can create a new C4C keypair from the Communication Arrangement and update your CPI.

We have two attached emails for certificate updates, and we are confused about the updates required and their sequencing. In the past also faced several issues over certificates which resulted in business disruptions. We would like to get the following information:

Which certificates are to be updated? Do we have to download from both notes?

Passport CA G2 Validity Extension: this renewal is planned in April end. Customer communications have been broadcasted by our Operation Team. Customer needs to update their integration systems and business communications arrangements.

You can refer to the following KBA article: Invalid Certificate Chain Error When Uploading C4C Certificate into CPI Key Store (https://itsm.services.sap/kb_view.do?sysparm_article=KB0759480)

Do we have to update both C4C and CPI?

Yes, you need to update it before May 14th

We created a service key inside the BTP Integration Suite so that the C4C can log in with the M-Certificate. There is no option to add some certificates to a trust list.

That said: We can leave everything as it is, and our communication will not break after the 14th of May. Even if the chain of the M-Cert is not valid anymore, cause the BTP does not care?

You do not need to change the current Service Key since the child M-user certificate remains the same.

The only action required refers to removing from your CPI Trust list the SAP Passport CA G2 (with the validity to May 14th ) and replaced by the new SAP Passport CA G2 which contains the extended validity date.

Do I need to be concerned about the M-User (Mandate)/Tenant certificate due to this renewal as well?

The M-user is signed by SAP Passport CA G2, however it remains the same. The M-User certificate is updated via SAP Background job which runs 60 days before its expiration.

It will automatically renew the certificate and triggers the notifications with the subject 'Tenant Certificate has been renewed'.

Please refer to the blog: https://community.sap.com/t5/crm-and-cx-blogs-by-sap/all-about-tenant-certificate-renewal-in-sap-cloud-for-customer/ba-p/13469059

Domain Certificate *crm.ondemand.com

Renewal of C4C Domain or Tenant certificate common questions:

What is expiring on 30th April 2024 and what will be impacted due to this?

Domain Certificate (*.crm.ondemand.com) validity is expiring on 30th April 2024. If you have used this certificate anywhere in your integrations previously, then you may need to update the attached one from the KBA #3119755. Also, since the chain of the certificate is also being changed, so you need to update entire chains in your trust store.

Below are the details of the attachment from KBA #3119755.

Root Certificate: “TrustedRoot.crt” à Subject/CN = “DigiCert Global Root G2”
Intermediate Certificate: “DigiCertCA.crt” à Subject/CN = “DigiCert Global G2 TLS RSA SHA256 2020 CA1”
Leaf/Domain Certificate: “star_crm_ondemand_com.crt” à Subject/CN = “*.crm.ondemand.com”

Note: This change is not applicable if your tenant is Akamai enabled, (To check if your tenant is Akamai ION/IPA enabled or not, Please refer the KBA #3119733 under the Resolution section).

Domain certificates as per communication will expire on April 30th and change will be executed between April 26th and April 28th for prod. So when do we have to update the certificates from our side?

It will be renewed on the announced date as per the communication email and this will done by SAP, If you are using this certificate in your integrations, then you may need to download and update it accordingly.

Does that mean we have to upload before this date?

Yes, you can upload and add the new certificate in your trust stores before, but that would be effective from the date we renew it at the backend, so it is good to do it before but still, you can do it after the above dates. In-case you are Akamai-enabled customer, then you don't need to do anything.

You can download the new certificate attached in the following KBA which I created to elucidate the procedure as well as the date details: https://launchpad.support.sap.com/#/notes/3119755

Please note: this change does not affect customers using AKAMAI

Shall we update before 26th April, between 26th and 28th, or between 28th to 30th April?

This certificate *.crm.ondemand.com Domain Certificate Renewal at Origin end' says Change will be executed from April 12th 18:00 hrs UTC to April 13th, 2024, 11:00 hrs. UTC for Test Systems.

General Splitter in CI - Namespace Prefix Problem

2024-04-26T13:52:11.421000+02:00

Hello together,

In Cloud Integration, the General Splitter can be used in Integration Flows to split a payload in multiple segments and process each segment individually. However, if global namespaces are involved, the General Splitter might not work as expected. If not configured correctly, it behaves as if the payload was empty which means that the following steps are not executed.

In our example Integration Flow, we fetch data from a webservice using an HTTP adapter and split the response message before calling a Local Integration Flow.

The response message looks as follows. It contains multiple entry elements which should be processed individually.

When using the XPath expression //entry in the General Splitter, the splitting step does not produce any output, so the following steps in the Integration Flow are never reached.

We show three approaches to get around this problem.

1. Removing Namespaces

We remove the namespace information from the XML file by introducing an XSLT mapping step.

In our example, we use the following XSLT mapping which also simplifies the payload a bit.

<!--
    XSL stylesheet for removing namespace prefixes and declarations.
    The stylesheet also removes XML elements that are not needed
    for the following steps.
-->
<xsl:stylesheet version="1.0"
	xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
	xmlns:m="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata"
	xmlns:d="http://schemas.microsoft.com/ado/2007/08/dataservices"
	xmlns:a="http://www.w3.org/2005/Atom" exclude-result-prefixes="m d a">

	<xsl:template match="/">
		<feed>
			<xsl:apply-templates select="//a:entry" />
		</feed>
	</xsl:template>

	<xsl:template match="a:entry">
		<entry>
			<xsl:apply-templates select="a:content" />
		</entry>
	</xsl:template>

	<xsl:template match="a:content">
		<content>
			<xsl:apply-templates select="@*|node()" />
		</content>
	</xsl:template>

	<!-- templates to remove namespace prefix -->
	<xsl:template match="d:*">
		<xsl:element name="{local-name()}">
			<!-- <xsl:apply-templates select="@*|node()"/> -->
			<xsl:apply-templates select="node()" />
		</xsl:element>
	</xsl:template>
	<xsl:template match="m:*">
		<xsl:element name="{local-name()}">
			<xsl:apply-templates select="@*|node()" />
		</xsl:element>
	</xsl:template>
</xsl:stylesheet>

After adding the XSLT mapping step the General Splitter works as expected when using //entry XPath expression.

2. Adding Namespace Information to the XPath Expression

The probably most straightforward solution is to add namespace information to the XPath expression. Since the XML file's root element feed belongs to the namespace http://www.w3.org/2005/Atom, all the other elements - including entry - also belong to this namespace as long as no other namespace is specified for them. Therefore, we add a namespace prefix atom and the namespace URL to the XPath expression as follows:

//atom:entry xmlns:atom="http://www.w3.org/2005/Atom"

3. Adding Namespace Information Globally

It is also possible to add the namespace declaration globally in the Integration Flow's Runtime Configuration. This is the best solution if a namespace is used at multiple places.

In our example, we enter xmlns:atom=http://www.w3.org/2005/Atom as Namespace Mapping.

After that you can use the name of the namespace mapping in the General Splitter.

Conclusion

We showed three solutions to get around problems when using the General Splitter for dividing payloads with a global namespace. We hope this information can help you if you are struggling with the same problem.

Further information about this topic can be found on the SAP Help Portal: General and Iterating Splitter Examples

We are open for improvements and questions.

Monika and Henning from Integration Team
RealCore Group

How to Leverage SAP CI and APIM for Hyperlink with Query Parameters as Input and no Authentication

2024-05-03T08:29:01.710000+02:00

Introduction:

This blog explains a method to transform the SAP Cloud Integration(Integration Suite) iFlow HTTP URL into a clickable hyperlink through SAP APIM.

P.S: This marks my debut in the world of blogging!

Requirement:

Imagine a scenario where a client procurement platform generates a link containing input data as a query parameter, but it lacks proper authorization. Our objective is to create a hyperlink that exposes the SAP CI iFlow URL. This hyperlink would send a response after forwarding the request to the target system. However, we are facing below challenges in this process.

The URL query parameter is not encoded, potentially causing errors when directly used in the SAP CI iFlow URL.
Lack of authentication poses a significant challenge, as SAP CI requires at least basic authentication.

Solution:

SAP APIM acts as an intermediary layer between the client procurement buying platform and SAP CI iFlow addressing the challenges mentioned above. Here's how it works:

Encoding: SAP APIM ensures that query parameters are properly encoded before transmission to the SAP CI iFlow.
Authorization Handling: By leveraging SAP APIM, authorization mechanisms can be implemented in APIM. The APIM also ensures that only authorized requests are passed on to SAP CI iFlow using IP whitelisting hence enhancing security and compliance.

Setup in SAP API Management:

For initial setup including creating the API Provider, API Proxy, and configuring the iFlow URL along with authentication we can refer the instructions outlined in this blog.
Based on this blog we can implement the IP whitelisting to exclusively permit client IPs to pass through the APIM thereby reinforcing security measures.

Integration Flow Design in SAP CI:

Let's begin by examining the sample URL generated by the client procurement platform.

https://SAP_APIM_URL?purchasingUnit=123&AccountAssignment=Test23&FieldValues={2=546,3=6290459,7=X02,}

In the URL above we will notice that the input data is contained within query parameters. Below we will explore how SAP CI iFlow transforms these query parameters into the desired XML format.

Sample CI iFlow:

1. Configure HTTP Sender:

Set up the HTTPS sender adapter with the Address field starting with '/'. Once the iFlow is deployed we will obtain the iFlow endpoint URL which will then be configured in SAP APIM.

2. Groovy to Get Query Params :

With the below Groovy script (based on this solution ) each query parameter is being stored in a header.

import com.sap.gateway.ip.core.customdev.util.Message
import java.util.HashMap
import java.net.URLDecoder

def Message processData(Message message) {
    def params = [:]
    (message.getHeaders().CamelHttpQuery =~ /(\w+)=?([^&]+)?/)[0..-1].each {
        params[it[1]] = URLDecoder.decode(it[2], "UTF-8")
    }
     
    message.setHeader("purchasingUnit", params.purchasingUnit)
    message.setHeader("AccountAssignment", params.AccountAssignment)
    message.setHeader("FieldValues", params.FieldValues)
    return message
}

3. Groovy to Get Key values:

The below Groovy script is utilized to extract and store each value corresponding to specific keys from the 'FieldValues' query parameter, which contains a key-value map. For example, keys like '2' correspond to 'CostCenter', '3' corresponds to 'Account' and so forth.

import com.sap.gateway.ip.core.customdev.util.Message;

def Message processData(Message message) {
    def headerString = message.getHeaders().get("FieldValues");
    
    if (headerString != null && headerString instanceof String) {
        def keyValuePairs = headerString.findAll(/\d+=\w+/);
        
        keyValuePairs.each { pair ->
            def keyValue = pair.tokenize("=");
            if (keyValue.size() == 2) {
                def key = keyValue[0].trim();
                def value = keyValue[1].trim();
                message.setProperty("key_" + key, value);
            }
        }
    }
    return message;
}

This script will store the values in a property, as illustrated in the screenshot below.

4. Mapping to target XML:

Creating the output XML is straightforward we will match the headers and properties from our previous Groovy scripts with their respective target fields.

Here are examples of how we have mapped the headers and properties to their corresponding target fields.

5. Groovy Script to send response:

After sending the XML to the target system we will receive a response indicating either success or failure along with an error message if applicable. The following script will generate a basic HTML response based on the received response.

import com.sap.gateway.ip.core.customdev.util.Message
import groovy.xml.*

def Message processData(Message message) {
    def body = message.getBody(java.lang.String) as String
    def xmlNode = new XmlSlurper().parseText(body)
    def headers = message.getHeaders()

    def returnCode = xmlNode.ReturnCode.text()

    if (returnCode == "success") {
        // Set success response in HTML format
        def successMessage = headers['FieldValues']
        def successBody = "<html><body><h1>Account Validation:</h1><h2>Account validation successful for combination $successMessage</h2></body></html>"
        message.setBody(successBody.getBytes("UTF-8"))
        // Set content type to text/html
        message.setHeader("Content-Type", "text/html")
    } else {
        // Set error response with ErrorMessage in HTML format
        def errorMessage = xmlNode.ErrorMessage.text()
        def errorBody = "<html><body><h1>Account Validation:</h1><h2>Error: $errorMessage</h2></body></html>"
        message.setBody(errorBody.getBytes("UTF-8"))
        // Set content type to text/html
        message.setHeader("Content-Type", "text/html")
    }

    return message
}

Testing:

Now, let's test some sample scenarios.

Case 1: Success Scenario

In this scenario, when the call is made to the URL from the client's IP address and the target response is successful the user will receive a similar response as shown in the screenshot below.

Case 2: Error Scenario:

In this scenario, when the call is made to the URL from the client's IP address and the target response is failure/error the user will receive a similar response with error massage as shown in the screenshot below.

Case 3: Invalid IP:

In this scenario, if the request is made to the URL from a non-client IP address the error displayed below will appear. The error is thrown at the SAP APIM layer itself thereby the request is not sent to SAP CI iFlow.

Conclusion: This blog explains the process of transforming a SAP CI iFlow URL into a clickable hyperlink(the legacy sender system lacks to provide any authentication) while extracting input data from query parameters and constructing the target XML. By leveraging the concepts outlined in this blog we can extend our capabilities to execute more complex integrations using similar methodologies.

SAP Pipeline Concept and B2B TPM testing

2024-05-06T07:30:00.023000+02:00

Abstract

With the introduction of the SAP Pipeline Concept we now have a second large use case apart from B2B-TPM which allows processing different types of messages with a set of predefined generic iflows. This blog will show a few ways how automated testing of such scenarios can be set up of the box with Int4 Shield - SAP Integration Suite testing platform and how SAP Integration Suite customers already use it for such scenarios.

SAP Pipeline Concept and B2B TPM - multiple iflows

In the pipeline concept, each step corresponds to an integration flow (generic integration flows and scenario-specific integration flows). The generic integration flows are used across all integration scenarios and must only be deployed once while scenario-specific integration flows handle the scenario-specific message conversions and mappings.

File Source: https://community.sap.com/t5/technology-blogs-by-sap/introducing-the-new-pipeline-concept-in-cloud-integration/ba-p/13639651

Similarly the B2B-TPM the exchange is divided into sender communication iflows, interchange processing and receiver iflows.

File source: https://community.sap.com/t5/technology-blogs-by-sap/use-tpm-ia-ci-to-efficiently-manage-and-run-complex-b2b-transactions/ba-p/13565068

Cloud integration is very flexible in terms of modeling and running your integration scenarios allowing the design of a rich variety of integration patterns on the other hand for some types of scenarios we may want to use a more "formal" way or processing and this is there SAP Pipeline Concept and B2B-TPM scenarios come in handy with some of it's common advantages:

a) Provide commonly used restart capabilities
b) Simplifies operations by separating errors into different generic queues
c) Require lower number of JMS queues to take into account the resource limits
d) Simplify monitoring operations
e) Allow reusability of artifacts across multiple flows by using generic (Pipeline or TPM) iflow concept

SAP Pipeline Concept and B2B TPM - testing

Since those two frameworks are going to be used more and more and they involve several iflows to be tested
is there any way to automate the testing of such integration processes? With Int4 Shield - SAP Integration Suite testing platform, there out of the box we have several ways to implement automated testing of the SAP Pipeline Concept and B2B TPM. Let me explain, how they work.

Step 1

In both SAP Pipeline Concept and B2B TPM we're working with multiple iflows so we may want to inject the test messages into a specific iflow. This can be the first iflows but does not have to be as we may want to skip testing the initial iflow in some cases.

Figure - Int4 Shield inject test message options

Step 2

Now we need to decide what do we want to test. What are the options? Basically two:

a) we can either test the whole framework (SAP Pipeline Concept and B2B TPM ) from start to finish

b) we may want to test specific iflows of the whole framework (SAP Pipeline Concept and B2B TPM)

For this purpose Int4 Shield automatically enables Trace monitoring level on tested iFlows to be able to introspect processing inside of these steps.
Thanks to this Int4 Shield can validate payload content at any single execution block of the processing steps.

Figure - Int4 Shield inject test message and trace start with validation options

Step 3

Scenario 1 (single automation object) - for simple black box testing, Int4 Shield injects the message in the initial step and awaits for logs and payload to arrive at the final processing step, capturing the output payload, as it would be sent to a target system. Single test case and single automation object is sufficient for test and validation.

Figure - Int4 Shield validation option with a single automation object

Scenario 2 (combination of automation objects - API workflows testing) - thorough testing is made possible with more test cases that execute more validation steps. In a typical scenario there is separate validation of Step 2 - to check if payload input was properly processed by Step 1 logic, and for Step 3 - to validate the output payload after mapping is correct and routed to the expected channel.

Figure - Int4 Shield validation option with a a combination of automation objects - API workflow testing

SAP Pipeline Concept and B2B TPM - framework support

Int4 Shied testing concept for SAP Pipeline Concept and B2B TPM supports:

a) Multiple adapter types : SFTP, JMS, HTTP, IDOC, ProcessDirect, SOAP
b) Enabling unit testing of specific flow components
c) Testing business flows with Inputs and Outputs from different iFlows
d) Test complete SAP Pipeline Concept and B2B TPM execution with one test case
e) Capture and test intermediate results from specific iFlow steps
f) Test complete SAP Pipeline Concept and B2B TPM execution, validating document flow through the iFlows
g) Massive and automated test case creation
h) Test case loader - mass load of test files
i) Robotic crawler - automatic capture of historical data from another integration platform
j) Test scenario builder - linking multiple test cases into test scenarios automatically based on message content (e.g. document numbers)

Additional resources

B2B/TPM on SAP BTP Integration Suite migration (SAP PO, Boomi, EDI Providers and home-grown apps)

Int4 Suite for SAP BTP Integration Suite testing fully integrated with SAP Cloud ALM

4 big waves for API led strategies and SAP BTP Integration Suite explosive growth

There is no AI without API - Integration is the backbone of digital transformations

SAP Inside Track Kolkata 2024: A Beacon for Future SAP

2024-05-07T14:01:56.525000+02:00

The year 2024 brought with it a groundbreaking event in the world of SAP: SAP Inside Track Kolkata 2024. This event served as a pivotal moment, not only shining a spotlight on the future of SAP careers but also delving into the critical realm of cloud integration. One of the all esteemed speakers Mr. Rajsekhar Venkatachalaiah, whose presentation on cloud integration within SAP SuccessFactors left a lasting impression for all the participants from SAP HR background.

The Significance of Cloud Integration

Cloud integration has emerged as a cornerstone of modern business operations. Its importance cannot be overstated in today's technology landscape, where connectivity, scalability, and accessibility reign supreme. Integrating cloud services enables organizations to revolutionize their operations in several key ways:

Seamless Connectivity: Facilitates smooth data exchange between systems, enhancing collaboration and efficiency.
Scalability: Enables organizations to adjust resources dynamically, ensuring optimal performance in changing environments.

Accessibility: Provides flexible access to business applications and data from anywhere, improving productivity.

Cost Reduction: Lowers infrastructure costs and complexities, freeing up resources for innovation and growth.

Cloud Integration in SAP SuccessFactors: Insights from Mr. Rajsekhar Venkatachalaiah

Mr. Rajsekhar Venkatachalaiah's presentation at SAP Inside Track Kolkata 2024 delved into the specific benefits of cloud integration within SAP SuccessFactors, a leading HR management system. Through insightful business scenario-based discussions and live demonstrations, Mr. Venkatachalaiah illuminated the transformative potential of cloud integration in SAP SuccessFactors through with Embedded Foundation Object (EFO) solutions. These solutions offer an organized framework for developing scalable and personalized HR solutions within the SAP ecosystem. With the pre-configured HR functions and best practices that EFOs provide, businesses may expedite HR procedures and guarantee uniformity amongst various SAP SuccessFactors modules and apps. Organizations can expedite the following arrears inside an organization by utilizing EFOs:

Optimizing HR Operations: Streamline talent management, payroll processing, and performance evaluation processes, enhancing efficiency.
Enhancing Employee Experience: Deliver personalized experiences through self-service portals, training resources, and performance feedback, boosting engagement and productivity.

Enabling Data-Driven Insights: Aggregate and analyze HR data to derive actionable insights, optimize workforce planning, and drive strategic initiatives.

Introducing Joule: A Conventional Supportive Pattern

As part of his presentation, Mr. Rajsekhar Venkatachalaiah introduced Joule, a revolutionary tool designed to enhance user experience within SAP SuccessFactors. Joule embodies three conventional supportive patterns:

Navigation Assistance: Joule guides users through SAP SuccessFactors' features efficiently.
Task Optimization: It offers step-by-step guidance to streamline task completion and boost productivity.

Information Retrieval: It facilitates quick access to relevant information, aiding faster decision-making by minimizing search time.

In Conclusion, SAP Inside Track Kolkata 2024 was not just an event; it was a catalyst for change, illuminating the path towards a future where SAP careers thrive and cloud integration revolutionizes business operations. Through insightful presentations like Mr. Rajsekhar Venkatachalaiah's, attendees gained valuable insights into the transformative potential of cloud integration in SAP SuccessFactors and the innovative tools shaping the future of user experience.

@DataTherapist

SAP Inside Track

SAP SuccessFactors platform

How to build SOAP service in SAP Cloud Integration, Part 2

2024-05-08T17:44:34.750000+02:00

SOAP request body

We need to call the SOAP service with some input data. In our case it is the invoice id, hence we need to send an http POST request with an XML body, which will contain this invoice id. But what will be the format of that body?

There are several ways how to create a sample XML body for a SOAP service. It will be always based on the WSDL, which we generated to construct the SOAP sender. We did that with the help of ChatGPT, so why not to ask there? The request to ChatGPT can be as simple as:

'Create sample SOAP body, used as the POST call against this WSDL' and paste the WSDL from previous blog post.

We will get a sample code, which we can just copy, as indicated. I am also attaching the code to this blog post.

Call SOAP endpoint from Postman

To call our endpoint from Postman, we will need

URL of our SOAP service iflow
credentials
body - paste the code provided by ChatGPT

We send it as POST request and we should get the hard-coded output values from our iflow.

Call SOAP endpoint from SCI

For this scenario we create a simple iflow starting with Timer, by default set to 'Run Once', which means the event will be triggered once we deploy the iflow.

Another component is a Content modifier, where we just paste our XML body content into the Body section.

Another component is Request Reply, which we connect to Receiver component using SOAP adapter (type SOAP 1.x). Our iflow could look like this now:

Double click on the dashed-line SOAP adapter and configure it as depicted on the screenshot.

Address - fill the URL of our SOAP Sender endpoint (see previous blog post)
URL to WSDL - select our WSDL (again from previous blog post) saved at your desktop
Service, Endpoint, Operation Name gets filled automatically from the WSDL.
Authentication - up to you, I chose Basic
Credential Name - alias of your basic credentials, saved in Security Material in SCI. These credentials have to be first created as Service Key within the SAP BTP Cockpit. If in doubts how to achieve that, please follow the documentation: https://help.sap.com/docs/cloud-integration/sap-cloud-integration/creating-service-instance-and-service-key-for-inbound-authentication

Now save and deploy the iflow. It will end up in error: The PayLoad elements cannot fit with the message parts of the BindingOperation. Please check the BindingOperation and PayLoadMessage.

Overcoming this error can be a little frustrating, as the same request from Postman went through just fine. The thing is, that as we used the SOAP adapter, this adapter treats the message in its own way, so we have to:

Remove envelope lines from the message
Add namespace. Click anywhere in the iflow canvas, go to Runtime Configuration tab and see the Namespace Mapping

We just modify the namespace mapping a bit and the final result of our request body is this:

<tns:GetInvoiceRequest xmlns:tns="http://example.com/invoiceservice">
   <tns:orderId>123456</tns:orderId>
</tns:GetInvoiceRequest>

Now save and deploy the iflow again. The request should go through and return the same result as did in Postman. You can see the payload in Trace mode or have it logged by a Groovy script component.

SAP Integration Suite - Design Guidelines in the integration flow editor of SAP Cloud Integration

2024-05-09T14:14:31.763000+02:00

Introduction

Design guidelines feature is available in the integration flow editor of SAP Cloud Integration with the 5.59.x/6.51.x to help integration developers to design and develop enterprise-grade integration flows. To know, you can refer the help documentation Design Guidelines | SAP Help Portal and Design Guidelines View | SAP Help Portal.

In this community blog, I will give a short overview on the design guidelines. Let us understand the fundamentals of the design guidelines prior having a deep dive.

What are Design Guidelines?

Integration flow design guidelines enable integration developers to design and develop integration flows, interfaces in a robust fashion to safeguard the company's mission critical business processes.

In the past, these design guidelines were recommendations that were published as product help and prepackaged content on SAP Business Accelerator Hub. You can find the guidelines in the Integration Flow Design Guidelines section. Now, the same guidelines are incorporated within the software as rules that help integration developers for easy consumption.

Why Design Guidelines?

Integration flow design guidelines help to improve the quality of the integration flows, interfaces by keeping them readable, easy to understand, avoid memory leaks, avoid performance overhead and helps handling error in a good way.

Motivation

Design guidelines helps understand the basic capabilities for modeling integration flows.
Provides guidelines to implement the basic enterprise integration patterns.
It helps to improve the performance of integration flows and reduce the possibility of the outages related to OOM, memory consumption etc.
It applies highest security standards.
It enables the integration flows ready for the productive usage.

Availability

Design guidelines are available in the SAP Cloud Integration across Standalone NEO, Cloud Foundry, and Integration suite.

Personas

Broadly there are two personas involved in the design guidelines configuration and execution process. Please check their roles and responsibility.

Persona	Responsibility
Tenant administrator/Integration Lead/Solution Architect	Configure the design guideline at the tenant level to make it available for all integration flows. Review the design guidelines compliance report and take a decision for the Go-Live in the production environment.
Integration Developer	Execute the design guideline on the integration flow. Download the compliance report and share with tenant administrator/integration lead for the review.

Workflow

Below diagram depicts the workflow that will benefit you in the usage of the design guidelines. Broadly there are two personas who will be involved in leveraging the benefit of design guidelines.

Tenant administrator, who will enable the design guidelines at the tenant level and integration developer who shall execute the guidelines on the integration flow to improve the quality.

Our recommendation is to impose the below process which will help to improve the quality of the integration flow and ensure the smooth transition for the go live in the production environment.

Let me try to explain the process by taking a following scenario into consideration.

Configure Design Guidelines

Configuring and enabling design guidelines is the responsibility of the Tenant Administrator/Integration Lead/Solution Architect.

We have a dedicated application role for the tenant administrator in NEO and Cloud Foundry. Please refer this documentation Persona | SAP Help Portal

However, tenant administrator can create a custom persona such as solution architect or Integration lead to manage and configure the design guidelines at the tenant level by using the role “WorkspaceDesignGuidelinesConfigure”.

User having a proper authorization will be able to see Design Guidelines tab in the integration settings page of the Integration Suite tenant.

Before you enable/disable design guidelines, understand every design guideline and its implications. Consume the in-app help available for each design guideline to learn more.

You can enable the design guidelines that you think are appropriate for your organization's requirements. Similarly, disable the ones that you think aren't appropriate anymore.

The design guidelines are logically grouped. For example, all transaction handling related guidelines are grouped under a single category. Some of the logical groupings are Handle errors gracefully and run an integration flow under well-defined boundary conditions.

Severity decides the criticality and importance of the design guidelines. Severity of the design guidelines is categorized as High, Medium, and Low.

Design guidelines which are switched-on will be applicable to the integration flows for the execution.

It is desirable that you like to follow the same design guidelines in your other development tenants, hence, to ease the work, we have offered export/import feature to export the design guidelines with the enabled/disabled status from one tenant and import the same in another tenant This way, you don't have to manually enable the same design guidelines in multiple tenants.

Execute Design Guidelines

As we discussed, design guidelines are rules that help you design robust integration flows. Your tenant administrators or integration leads would have enabled all or a subset of available design guidelines that they think are appropriate for your organization's business needs.

Integration developer responsibility would be to execute the design guidelines after they have developed the integration flow. You can also run the guidelines on the already developed integration flows as well.

Guidelines which are mandated by the tenant administrator or Integration lead will participate in the execution of the design guidelines on the selected integration flow.

Remember that not all enabled design guidelines are applicable for every integration flow that you create. The integration flow editor intelligently identifies the design guidelines that are applicable and validates the integration flow only against the applicable ones. Applicability – “Not Applicable” means the corresponding guidelines is not applicable to your integration flow.

Compliance status can be either “Compliant” or “Non-Compliant”. If the integration flow is not compliant to the guidelines, then analysis report will be provided which will educate integration developer how to fix the failed guidelines and ensure the quality of your interface. Analysis will also cover the model step where the fix must be applied. Easy navigation to the problematic step of the integration flow is offered to ease the job of the integration developer.

Once the design guidelines are made compliant, our recommendation is to download the report and share with the integration lead/Tenant administrator/Solution Architect so they can review the guidelines report and take a decision for transport of the integration content to the production environment for the Go-Live.

FAQs

In which product of SAP Cloud Integration, design guidelines feature is available?

Design guidelines is available in Cloud Integration NEO, Cloud Foundry, and Integration Suite all editions.

Who can configure, enable/disable design guidelines at the tenant level in the integration settings page?

Tenant administrator or the user having the application role – “WorkspaceDesignGuidelinesConfigure”.

Do the non-compliant design guidelines lead to integration flow deployment failure?

No.

Do the non-compliant design guidelines lead to content transport failure?

No.

Can I execute design guidelines on the standard pre-packaged integration content?

Yes, you can execute design guidelines on standard and custom integration content.

Can I execute design guidelines on the read-only Integration flow?

Yes.

Who can execute design guidelines on the integration flow?

Integration developer can execute the guidelines on the integration flow.

Do the support users are allowed to download design guidelines compliance report?

No, they cannot download the report. However, they can visualize the guidelines compliance result in the integration flow editor.

Can I know when the last time the design guidelines was executed on the integration flow?

Yes, we show the datetime information in the design guidelines tab of the integration flow after the guidelines are executed.

Can I know on which version of integration flow the design guidelines was executed?

Yes, we show the integration flow version in the design guidelines tab of the integration flow.

Can integration developer remove the design guidelines which are mandated by the tenant administrator?

No, guidelines which are mandated cannot be removed by the integration developer from the execution.

In which format I can download the design guidelines compliance report

Report is available in the xls format.

What’s coming next?

We have the following increments planned in the succession.

Increase the coverage by adding more design guidelines for the integration flow.
Skip design guidelines – If the design guidelines fail (i.e., non-compliant), we want to offer a feature for the integration developer to skip the failed design guidelines with his/her consent mainly to block the false positive guidelines failure.
Public Remote APIs for enabling CI/CD requirements.
Restrict deployment and transport of the integration flow but via a proper governance and transparency.
Enable design guidelines in the Script Collection, Message Mapping, and other applicable artifacts.
Custom design guidelines for the customers to write their own custom rules.

I am also planning to write a developer tutorial with an example. Stay tuned !

Hope you will get benefited with this feature. Please experience the feature and provide your valuable feedback.