Design – 1st we have to create a package and inside the package we create IFlow.

Click on ‘Create’:

Click on ‘Save’.
Go to ‘Artifacts’, Add – Integration Flow:

‘Sender’ and ‘Receiver’ we can directly configure from here, these are externalized parameters. We can
externalize it internally also.
The IFlow has been created. The version shown is 1.0.0.
Basic component of the IFlow – Sender, Receiver and Integration Process.
We can have many senders and receivers but only one integration process.
Copy and paste buttons shown above. If we want to copy the sender and receiver systems, or any
components inside the Integration Process, we use these buttons. We can copy and paste the components
in any other IFlow. We can copy and paste any reusable components in other IFLows.
Participants sender and receiver. We use this to add extra sender and receiver.

Process We have 3 processes – Exception subprocess, Integration Process and Local Integration
Process.

Integration Process – we use it to define the steps, process the message to transfer between sender and
receiver. Message processing and data processing takes place in Integration Process.
Exception Subprocess – configured inside the integration process. Used to catch any exception thrown in
the integration process to handle them, so that the integration process doesn’t fail.
Local Integration Process – Used to simplify the integration process like suppose we have a very
complex integration process which requires so many components. Local Integration Process is used to
break down a main big integration process into smaller fragments. We can combine these fragments to
achieve the main integration process.
Events
End Event – To end any integration process, we use the end event.

End message – Ends the message event, ends a message processing sequence.
Escalation End Event – Used for routing conditions that have not been met.
Error End Event and Error Start Event – we get in Exception Subprocess.
Add ‘Exception Subprocess’:

We have ‘Error Start1’ and ‘End 1’.

Start Event –

Start Message – is to start the message processing.

Terminate Message – is to terminate the message.
Connector Line –

Mapping –

ID Mapping – used to map unique ID from source to target message ID.

Message mapping – Used to map the message or map the data. Suppose the source data with different
fields have to be mapped to target with different fields. We have to explicitly map the source and target
data (Which data from source is going to which field to the receiver).
Operation Mapping – Rarely used.
XSLT Mapping – Extensibility Style Sheet Language Transformation Mapping. XML-based language is
used. Reduce our custom coding. No need to write JS or Groovy script.

Message Transformers:

Content Modifier – We add this to modify our content.

Message Header – We can add or delete header:

Exchange Property:

Message Body: We can add some message in the body:

Converter:

If we want to convert from CSV to JSON, we have to use 2 converters1st convert from CSV to XML and
then from XML to JSON.
Decoder:
Base64 Decoder – used to decode messages using Base64 technique.
GZIP Decompression, etc.
EDI Extractor: Enables you to extract EDI headers and transform to camel headers and this element
extract data from single incoming EDI document and add in message processing.

Encoders: To encode messages. Same techniques are available in Decoders.

Filter: Used to extract information from an incoming message. We can filter out parts of message that
you don’t want.
Message Digest: Used to calculate the digest of the payload and store in message header.
Script: We can do some custom coding here:

We can use it in message mapping.

Call:

External Call:

Content Enricher – Mechanism to combine the incoming message with additional data retrieved from an
external source.
As per its name (Enricher), adding something to the content. The content enricher adds the content of the
payload with the original message in the course of integration process and this converts 2 separate
messages into single payload and this feature enables you to make external call during the course of
integration process to obtain the additional data.
Poll Enrich – Polls to external system and enriches incoming message. We can use this to read the Poll
message from external component and add the content to the original message in the middle of the
message processing sequence.
Request reply – It represents call to external system. We use it to call an external receiver system in
asynchronous step to get back a response.
Send – Represents a one-way call to an external system. Used to configure a call to receiver system for
scenario and adapter where no reply is expected.
In request reply we expect a reply but in send we don’t expect a reply. We can use these in different types
of adapters. Like a Mail.
Local Call:

Message Routing:

Aggregator – With Aggregator we can collect and store individual messages until the complete set of
messages are received. Aggregates several incoming messages to a single one.
Gather and Join – Gather step gets messages from different routers with option to define certain strategy
to combine the messages. Gather defines the aggregation strategy. Join step is used in combination with
the gather step. It brings messages from different routers, but it must not affect the content of the
message. Join sends multiple incoming messages to a single outgoing path.
Multicast – Sends same messages to different paths.

We use this to send a message to more than one path.

Parallel Multicast – sends the same message to more than one path in parallel.
Sequential Multicast – sends the same message to more than one path in defined sequence.
Router – Exclusive decision and merging. Used if we want to send data in different directions.

Splitter – Breaks down a composite message into a series of individual messages.

Used to break down a single message into chunks.

Security:
Decryptor – Decrypts the encrypted data contained in the body of the incoming message.

Encryptor – Encrypts the content of the incoming message body.

Signer – Digitally signs the message content.

Verifier – Verifies the signature of the message content.

Persistence-

Data Store operations – Performs operations with data store.

Persist – Stores message payload at a process step.
Write variables – Add a write variable.
Validator –

Used to validate the schema or set of rules provided to the message.

Scenario 1: checking if CPI is working as expected or not.

We have access of an OData API and we have information of one product Id. We will send the
product Id through a content modifier to the OData and we will fetch more information about that
product using the OData.
ODATA API:
https://refapp-espm-ui-cf.cfapps.eu10.hana.ondemand.com/espm-cloud-web/espm.svc
In this scenario, we do not have any sender or receiver system.
Add a content modifier. – Add a ‘product Id’ inside the message body. This ‘productId’ is used to fetch
the information about the product from OData API.

Here we added 1 header ‘product identifier’.

We have to create this header.
Add a second content modifier – Here add the message header. While creating the message header, give
the ‘source type’ as XPath. Because we used XML coding in the previous content modifier to represent
the body data.

In CPI we use the data type ‘java.lang.String’ to represent a string. In CPI we use groovy script.
Request Reply – To use OData we have to add Request Reply, to the request reply we have to add one
receiver. Because we are sending request to OData to get the information about the product HT-1080.
Here to connect the request reply and receiver we use an adapter OData V2. We have to configure the
OData connection:
In the connection, we have to give the address of OData.
In processing, we use a GET call, we want data from OData.
Click on Finish.

We want the data to be seen in the monitoring section, so for that e have to do some groovy script. Like
we want to log the data.
Add ‘groovy script’ component in the Integration Process. There will be a ‘create’ option to do some
coding:

We want to just LOG the message. For this we used the above groovy script.
If we are using the groovy script in CPI, we have to import
‘com.sap.gateway.ip.core.custom.util.Message’
Without importing this, it won’t work in CPI.
Also, import ‘java. util.HashMap’.
We define a message to process the message data and in that we are defining the body, as a message
string.
We are logging the message and keeping it in the message log.
We are checking if the message log is not null, we will add the attachment as Log current Payload, in the
body as a plain or text. Then return the message.
‘Start’ is triggered when the data is sent from the sender system. Here we don’t have any sender system,
we have to use a timer. In the timer, there is an option- when we deploy it it will automatically start. We
can also configure the timing like:
‘Run Once’ when we deploy the IFlow, it will automatically go on the Run Mode.

Save and Deploy the IFlow.

In the monitor section, we can check that what IFlow we have deployed and what components are inside
it. In the ‘Manage Integration Content’,

Log level has a separate significance in CPI.

Log Level :
Info – At info level we don’t get much information. We get simple information like how the IFlow is
deployed.
Trace – If we want detailed information like after which step what is happening, we have to set it to
‘trace’. It will be in trace mode for 10 mins. Trace is available only for 1 hr.
Debug – Available for 24 hrs.
None – won’t be able to see anything.
‘Log current Payload’ – we have logged this using the groovy script.
We passed the product Id as HT-1080, we asked for the extra information present in it from the OData
API. This is because we used groovy script for logging the payload.
We we want to see more information, set the log to Trace mode.
We sent a request to OData and we got a Reply.