• Success
    Manage your Success Plans and Engagements, gain key insights into your implementation journey, and collaborate with your CSMs
    Accelerate your Purchase to Value engaging with Informatica Architects for Customer Success
  • Communities
    A collaborative platform to connect and grow with like-minded Informaticans across the globe
    Connect and collaborate with Informatica experts and champions
    Have a question? Start a Discussion and get immediate answers you are looking for
    Customer-organized groups that meet online and in-person. Join today to network, share ideas, and get tips on how to get the most out of Informatica
  • Knowledge Center
    Troubleshooting documents, product guides, how to videos, best practices, and more
    Knowledge Center
    One-stop self-service portal for solutions, FAQs, Whitepapers, How Tos, Videos, and more
    Video channel for step-by-step instructions to use our products, best practices, troubleshooting tips, and much more
    Information library of the latest product documents
    Best practices and use cases from the Implementation team
  • Learn
    Rich resources to help you leverage full capabilities of our products
    Role-based training programs for the best ROI
    Get certified on Informatica products. Free, Foundation, or Professional
    Free and unlimited modules based on your expertise level and journey
    Self-guided, intuitive experience platform for outcome-focused product capabilities and use cases
  • Resources
    Library of content to help you leverage the best of Informatica products
    Most popular webinars on product architecture, best practices, and more
    Product Availability Matrix statements of Informatica products
    Monthly support newsletter
    Informatica Support Guide and Statements, Quick Start Guides, and Cloud Product Description Schedule
    End of Life statements of Informatica products
Last Updated Date May 25, 2021 |


XML structures can be very complex and difficult to traverse. When facing the need to map a source XML structure to a target XML structure it can be difficult to design the mapper object in a way that will achieve the desired result.


The Data Transformation (DT) mapper object is used to retrieve data from a source XML structure and place it in a target XML structure that can later be used in other steps. The purpose of this document is to provide general guidelines on how to create the mapper object.

Mapper Structure

Before implementing the mapper object, input and output schemas (e.g., Source.xsd, Target.xsd) will need to be provided and/or created.

In many cases, when creating a mapper in DT, the differentiation of source and target structures causes complexity. A good strategy is to build the mapper based on either the structure of the source XSD or target XSD. This way, the logic (e.g., Groups, RepeatingGroups) will be nested to resemble the structure of the XSD, and the code will be readable and easy to maintain. It will also prevent or minimize the locator’s challenges.

For example, if the mapper is based on the source XSD and it contains a repeating element, then it should include a RepeatingGroupMapping that will loop on that element. In the same manner, a sequence becomes a GroupMapping, and a choice becomes an AlternativeMapping.


Since the source and target structures can be very different, it is crucial to make proper use of the locators in the mapper to avoid unwanted results. Examine the following scenario where there is a need to create a mapper between the following XSDs:

If the mapper structure will be based on the source XSD and there will be no use of target locators, then running the mapper on the following input

—will create the following result:

The result contains two Bank elements, even though only one was expected. Since there was no target locator in the mapper, an error occurred. Once the target locator is added —

—then, the desired result is generated:

Note: Placed in the right location, a map action causes the same behavior as a target locator.

Embedded Mappers

Embedded mappers should be implemented when the same mapping logic is used in multiple locations in the mapper in order to allow reusability of code.

For example, consider the next scenario: the source schema contains a sub element of type Address_Input in multiple locations. The target schema contains a sub element of type Address_Output in multiple locations. These elements are complex elements, and the mapper logic requires the mapping between them. In this case, a mapper between the elements Address_Input and Address_Output should be implemented and used as an embedded mapper wherever applicable in the main mapper (see images).

Note: The sub elements need to be defined as global elements in the XSDs in order to be used in the embedded mapper.

The mapper:

The embedded mapper with the schema connections:

Table of Contents


Link Copied to Clipboard