Design Reusable Transformation Components
Learning Objectives
After completing this unit, you'll be able to:
- Describe the purpose, structural components, and organizational benefits of mapplets in Cloud Data Integration (CDI).
- Identify best practices for determining when to build a mapplet.
- Differentiate between the mapplet design canvas and the standard mapping canvas.
- Organize reusable assets according to naming standards.
The Reuse Challenge
Cassie now manages over a dozen mappings across AW Computing. Several of these pipelines apply the exact same customer enrichment logic.
- Concatenate FirstName and Surname into FullName.
- Evaluate Order_Total to assign a CustomerTier (Platinum, Gold, Silver, Bronze, Standard).
- Look up regional mailing addresses from a reference file.
When she built her first pipeline, she built this logic inline on her canvas. As new requests came in, she copied and pasted those same transformation blocks into subsequent mappings. That manual approach worked fine—until AW Computing's marketing leadership adjusted the customer tier model, raising the Platinum threshold from $100,000 to $150,000.
Cassie now has to open, edit, validate, and re-save that expression transformation across six different mappings. In one mapping, she made a typo, causing corporate accounts to be misclassified in the daily leadership report. That single mistake cost her 2 hours of troubleshooting.
Cassie realizes she needs a modular, single-source-of-truth component that can be managed from one place.
Learn About a Mapplet
A mapplet is a reusable, self-contained transformation object in Cloud Data Integration (CDI). It encapsulates one or more transformations—including input definitions, business logic, and output parameters—into a single object that can be dropped onto any mapping canvas.
Think of a mapplet like a function in software development: you define the logic once, give it a name, and call it wherever you need it.
When business rules change, you update the logic inside the mapplet once. Every mapping that includes that mapplet automatically inherits the updated logic the next time it executes.
Anatomy of a Mapplet Canvas
When you open a mapplet in Cloud Mapping Designer, the canvas looks similar to a standard mapping canvas, with one critical difference: A mapplet typically does not contain source or target objects. Instead, it relies on dedicated input and output transformation objects to interface with parent mappings.
The table below describes the main components that make up a mapplet.
Mapplet Component | Canvas Object | Description |
|---|---|---|
Input Group | Input Transformation | Defines the incoming fields and data types the mapplet expects to receive from the parent mapping. |
Transformation Logic | Expression, Filter, Lookup, and so forth | The sequence of midflight transformations that clean, calculate, or enrich the incoming data stream. |
Output Group | Output Transformation | Defines the refined fields the mapplet returns to the main mapping flow downstream. |
When to Build a Mapplet
Whether to build a mapplet or rely on inline transformations depends on reusability, maintenance complexity, and team collaboration.
Build a mapplet when:
- Logic repeats: The exact transformation sequence appears in two or more mappings.
- Rules evolve: Business logic (such as tax calculations, tiering algorithms, or compliance filters) changes frequently and must remain consistent across pipelines.
- Teams collaborate: Multiple developers need to share vetted, standardized logic without rebuilding objects from scratch.
Use Inline Transformations when:
- The transformation logic is unique to a single pipeline and has no broader business application.
Mapplets Versus Inline Transformations
Feature Area | Inline Transformations | Mapplet Component |
|---|---|---|
Scope | Unique to one mapping canvas. | Shared across multiple mappings in an organization. |
Maintenance | Must be manually updated inside every mapping individually. | Change once in the Mapplet—all parent mappings inherit the change. |
Risk Profile | High—manual updates introduce drift, typos, and missing fields. | Low—provides a single, audited source of truth. |
Canvas Design | Uses physical Source and Target endpoints. | Uses functional Input and Output boundary blocks. |
Pro Tip: Inheritance and Validation
When you update and save a mapplet, parent mappings using that mapplet do not become invalid automatically unless you change the mapplet’s input or output field signatures (such as deleting an input field or renaming an output field). If you alter internal calculation logic without changing field signatures, the parent mappings execute the updated logic on their next scheduled run seamlessly!
Name and Organize Reusable Assets
To keep AW Computing’s workspace structured, Cassie stores all mapplets inside her Customer_Data subfolder within the project.
She strictly applies her team’s naming standard: mplt_[Description] (for example, mplt_EnrichCustomerRecord). The mplt_ prefix instantly tells any team member browsing the asset repository that the object is a reusable component rather than an executable mapping pipeline.
Cassie also completes the Description field on the mapplet’s General properties tab, documenting:
- The business purpose of the logic.
- Expected input fields (FirstName, Surname, Order_Total, CustomerID).
- Output attributes returned (FullName, CustomerTier, Street_Address, City, State).
This documentation surfaces in the asset preview panel whenever another developer hovers over mplt_EnrichCustomerRecord before dragging it onto their canvas, making cross-team collaboration effortless.
Wrap It Up
Cassie had been copying the same customer enrichment logic from mapping to mapping. When marketing raised the Platinum threshold, she had to edit it in six places, and one typo cost her two hours. A mapplet fixes that.
She builds the logic once, and every mapping that uses it picks up the change. Build one when the same logic shows up in more than one mapping, when the rules change often, or when a team shares the logic. Cassie keeps hers in the Customer_Data subfolder, uses the mplt_ prefix, and fills in the Description field so others know what it does.
Next, Cassie builds her first mapplet and drops it into a mapping.