In my previous two blogs discussed the comparisons between cloud integration (HCI) and on premise integration(PI/PO) and this is one more but this time it talks about the enriched features of HCI over it’s on premise tool.
1.Message Transformers:There are various options to influence the incoming messages apart from mappings, whereas in PI/PO only mappings transform the message.
Content modifier: This process step is used to modify the content of incoming message by providing additional information in the header or body of message. It supports parameters at header and properties level and these parameters are used in many places in iflow. for example channel dynamic configuration.
Dynamic configuration: - When we need to configure some parameters dynamically in communication channel, it is very easy to do with help of Content modifier.
1)create parameters in header and assign the xpath value of incoming message,2) assign the parameter to header through a very simple script ,3) use this parameter in communication channel.
In PI/PO it is not so simple, first we need to have dynamic configuration setup in message mapping (UDF), secondly in comm channel enable the Adapter specific message attributes. Like target url in receiver soap comm channel or file name or directory file Adapters.
Creating Parameter in Header of Content modifier:
Setting Parameter in Header of script:
Accessing Parameter in communication channel:
Script: This process step is used to execute Java script or Groovy script for message processing. It is used to modify Header, Body and Property.
This feature is not available in PI/PO
Filter: This processing step is used to extract the information from an incoming message. In other words, you filter out parts of the message that you don’t want and extract only the data you want.
This feature is not available in PI/PO but it can be done through mapping.
Input message:
Filter properties:
Output:
2.Message Routing: There are various steps in HCI to perform the message routing than PI/PO. In PI/PO message routing is done through receiver determination or ICO, sometime receivers can be determined in the mapping too. So HCI has very enriched Message-routing features like Multicast, Splitter and Router(Gateway).
Multicast: This process step is used to send the message to more than one receiver (flow) either parallel or sequential. In PI/PO no step exclusively like this, the same receiver determination can be used there you can send more than one receiver with routing condition or without.
multicast two Receivers/flows:
Splitter: Break down a message into multiple individual messages. There is no exclusive step like this in PI/PO but this can be done through multimapping 1: N and receiver determination. (normal interface or ccBPM)
In real time sometime we need to split the single Idoc into multiple idocs based on line item segments.
Setting splitter properties:
Aggregator: It bundles the incoming messages; it is N:1 vice versa to Splitter, that means it is used to combine multiple incoming messages into a single message. This feature is not supported in normal interface of PI/PO whereas it can be done through ccBPM or NetWeaver BPM.
Setting aggregator properties:
Router(Gateway): This process step is used to determine the receivers to deliver the messages. We can have routing conditions and all branches should have the same type of condition either xml or non-xml, we can make one of the branch as default.
In PI/PO it is normal receiver determination or ICO.
Bottom line HCI has various Options to perform message transformation and Routing than PI/PO because by default HCI is an integration process so it has more features. In normal interface of PI/PO we don't have wide range options but with help integration process(ccBPM/BPM) these functionalities canbe done..
1.Message Transformers:There are various options to influence the incoming messages apart from mappings, whereas in PI/PO only mappings transform the message.
Content modifier: This process step is used to modify the content of incoming message by providing additional information in the header or body of message. It supports parameters at header and properties level and these parameters are used in many places in iflow. for example channel dynamic configuration.
Dynamic configuration: - When we need to configure some parameters dynamically in communication channel, it is very easy to do with help of Content modifier.
1)create parameters in header and assign the xpath value of incoming message,2) assign the parameter to header through a very simple script ,3) use this parameter in communication channel.
In PI/PO it is not so simple, first we need to have dynamic configuration setup in message mapping (UDF), secondly in comm channel enable the Adapter specific message attributes. Like target url in receiver soap comm channel or file name or directory file Adapters.
Creating Parameter in Header of Content modifier:
Setting Parameter in Header of script:
Accessing Parameter in communication channel:
Script: This process step is used to execute Java script or Groovy script for message processing. It is used to modify Header, Body and Property.
This feature is not available in PI/PO
Filter: This processing step is used to extract the information from an incoming message. In other words, you filter out parts of the message that you don’t want and extract only the data you want.
This feature is not available in PI/PO but it can be done through mapping.
Input message:
Filter properties:
Output:
2.Message Routing: There are various steps in HCI to perform the message routing than PI/PO. In PI/PO message routing is done through receiver determination or ICO, sometime receivers can be determined in the mapping too. So HCI has very enriched Message-routing features like Multicast, Splitter and Router(Gateway).
Multicast: This process step is used to send the message to more than one receiver (flow) either parallel or sequential. In PI/PO no step exclusively like this, the same receiver determination can be used there you can send more than one receiver with routing condition or without.
multicast two Receivers/flows:
Splitter: Break down a message into multiple individual messages. There is no exclusive step like this in PI/PO but this can be done through multimapping 1: N and receiver determination. (normal interface or ccBPM)
In real time sometime we need to split the single Idoc into multiple idocs based on line item segments.
Setting splitter properties:
Aggregator: It bundles the incoming messages; it is N:1 vice versa to Splitter, that means it is used to combine multiple incoming messages into a single message. This feature is not supported in normal interface of PI/PO whereas it can be done through ccBPM or NetWeaver BPM.
Setting aggregator properties:
Router(Gateway): This process step is used to determine the receivers to deliver the messages. We can have routing conditions and all branches should have the same type of condition either xml or non-xml, we can make one of the branch as default.
In PI/PO it is normal receiver determination or ICO.
Bottom line HCI has various Options to perform message transformation and Routing than PI/PO because by default HCI is an integration process so it has more features. In normal interface of PI/PO we don't have wide range options but with help integration process(ccBPM/BPM) these functionalities canbe done..
- SAP Managed Tags:
3 Comments
