Informatica Cloud

Creating an iDoc Mapping in Informatica Cloud Data Integration

Scott S NelsonLeave a comment

One type of mapping I find particularly complicated to build is one using the SAP iDoc connector. The complicate part is achieving the correct value nesting. It is complicated because when you create the mapping, the nesting is not visible. It is created by the use of Primary and Foreign key fields (GPK and GFK in the mapplet).

I have seen several approaches to this that work and the approach I am going to share here is the one that I came up with and use because I understand it. YMMV.

First, I create a list of GPK and GFKs from the mapplet XML. These values can be found in the TRANFORMATION nodes within the MAPPLET node.

With this list in hand, I create the document GPK with a field that will be unique per iDoc. In this case I have a unique entity ID in my source and a date field that will make the entry for the entity unique. I prefix this key with the OTYPE because I may have multiple entries for the same object on the same date but different OTYPEs.

Creating the GPK_DOCNUM Value
Creating the GPK_DOCNUM Value

Then, for each immediate child, I define its GFK and GPK using the node names as prefixes:

Creating the GPK_E2PLOGI001 Value
Creating the GPK_E2PLOGI001 Value
Creating GPK_E2PITYP001 Value
Creating GPK_E2PITYP001 Value
Defining First Child of E2PITYP001
Defining First Child of E2PITYP001

The above examples goes three levels deep. If your iDoc requires nest your nodes in a different pattern, generate your GPK values in such as way that they can be properly created in both the parent and child node.

For ease of maintenance, I name the fields in the expressions the same as they are defined in the mapplet so that I can use Automatic field mapping, which is eliminates the need to manually re-map anytime I make a change:

Auto-mappping Fields for ease of Maintenance
Auto-mapping Fields for ease of Maintenance

I hope this saves you some of the time it took to get me to this approach.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson

Sometimes Two Processes are Better than One

Scott S NelsonLeave a comment

This is a short post to save people the time of discovering that what is usually thought to be more efficient is not in one case…

I’m working on some ETL integrations where the source is sometimes so complicated that it is too painful to work with it within the Informatica Cloud Mapping Designer. Fortunately, the customer also has Informatica Cloud Real Time, which has some handy APIs for accessing and re-arranging data from ReST and SOAP services. In one particular case I need to get check each record before sending the result set to a Mapping Task. I followed an example where one process calls a sub-process that is designated to apply to only the object type of the record being processed (a simplified version is depicted below).

Top Process calling Sub-Process for a List
Top Process calling Sub-Process for a List
Sub Process that Writes a Particular Object Type to a file.
Sub Process that Writes a Particular Object Type to a file.

This worked as described, though looking at the resulting process, it seemed that I could eliminate the sub-process by recursing the file writer call inside the first process.

One Recursive Process Writing a List to a File
One Recursive Process Writing a List to a File

The recursion approach worked, but it was much, much slower than the approach of handing off the file writing task to the sub-process. This seemed unexpected given the minimal processing being done, but there you have it.

Facebooktwitterredditlinkedinmail
© Scott S. Nelson