Since heard about HCI I am curious to know how this tool functions and its features, advantages over existing on premise tool PI/PO. After my SAP training slowly started working on this tool.

Overview:-Mapping comparisons of HCI and PI/PO. This blog talks about the mappings of HANA Cloud integration and the comparisons with the mappings of PI/PO (on premise).

JDBC/RFC lookup:- Mapping of HCI is as good as PI/PO message mapping. It supports all standard functions except ‘JDBC/RFC lookup’ conversion functions. So HCI mapping does not support ‘JDBC/RFC lookup’.

Parameters: – Parameters are not supported in HCI-mapping that means parameterized mapping is not supported in HCI.
Whereas parameters are supported in PI/PO, providing the values for parameters in interface determination or ICO . (Earlier parameters are not supported in ICO, but now parameters allowed in ICO)

UDF/custom function: – Earlier custom functions are not supported in HCI, now custom functions can be created in mapping, but these are groovy based scripts. Whereas udf in PI/PO are java, and it has simple udf and Advanced UDF (handling complete context/queue).

Note:-To handle context need to add ‘MappingContext’ as an additional argument

Test (simulation): – HCI mapping does not have any test feature to test the mapping during the development(in elipse). PI/PO mapping has that options and it is really useful to test the mapping during the development and during error handling.
HCI-mapping simulation can be done in the web ui, that means after deploying iFlow and then log in to web ui, there mapping simulation is available.

Multi mapping:-HCI-mapping supports multi mapping as good as PI/PO-message mapping. In general multimapping can be when there are more than one source message or target message, and when change the cardinality to 0…unbound or 0..1 (Occurrence). HCI-mapping supports this multi mapping feature.

Coupling:-Mappings in HCI are tightly couple with iFLOW.

  1. Reusability:- Because of this mappings cannot be reused in other iFlow. Whereas in PI/PO mappings can be reused as they are loosely coupled.
  2. Change handling: If a mapping needs a change or bug fix then entire iFlow should be deployed where as in PI/PO just fix the mapping and transport to production and no need of any other objects of that interface.

 XSLT mapping: – XSLT mapping is supported in HCI like in PI/PO. In fact in HCI we don’t need any external xml tools to build xslt mapping, in eclipse itself xslt-mapping can be developed it is really very convenient, where as in PI/PO we need to import this external xsl file as imported archive.

Mapping is stored under the package ‘src.main.resources.mapping’.

Mapping Execution: – Mapping in HCI is executed only one time for all its receivers, whereas in PI/PO the mapping is executed as many times as its receivers, that means if there are ‘N’ receivers mapping is executed ‘N’ times.

In HCI mapping is executed before the receivers determined, but in PI/PO receivers are determined first and then respective mapping is executed for each receiver.

Case 2: Sometimes every receiver has different requirement eventually need separate mapping for every receiver. In this case PI/PO has advantage as by default mappings in PI/PO are executed for every receiver.

To achieve this, need to adjust the iFlow design bit as shown in the below. We need to have separate mapping step for every receiver and place mapping step in the respective branch.

Overall mapping execution is better than in PI/PO. But message mapping editor in PI/PO(ESR) is quite convenient than eclipse editor. As we know mappings and operational mappings can be imported into HCI iFlow. UDF of the mappings from ESR will be supported in HCI-mapping but not sure in case of parameters. XSLT mapping editor in elclipse is value addition.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply