IBM WTX (From Redbook sg247693) - illyfrancis/scribble GitHub Wiki

3.1 Design Process

Modeling any data transformation in WebSphere Transformation Extender requires three steps. Figure 3-1 shows the steps to create a Transformation Extender solution.

  1. Analyze and describe the data (create type trees)
  2. Transform the data (create maps)
  3. Deploy the maps and systems

1. Analyze and describe the data.

In this step, you create type trees, which tell WebSphere Transformation Extender how the data is structured. You must understand the input and output data. In addition, you must perform the following tasks:

  • Identify the type of data in order to determine whether type trees can be generated by using an importer or the Database Interface Designer, or if you can use a predefined type tree.
  • If type trees cannot be generated, use the Design Studio to create type trees to describe properties and structures of input and output data.

2. Transform the data.

You must create maps that specify data transformation logic to be used when map is run.

3. Deploy maps and systems.

You must perform the following actions:

  • Link systems of maps together. If you are using WebSphere Transformation Extender with Launcher, you must create systems that link the maps and create a transformation workflow. For other runtime environments, it is enough to build and deploy the maps.
  • If your system is destined for the Launcher runtime, you must specify specific events that should start the execution of transformation workflows. The events can be based on incoming source data, or they can be time based. You then assign the system to a destination server.
  • Deploy completed maps and systems to production servers.

You use WebSphere Transformation Extender Design Studio to create the type trees and maps. Systems are created in the Integration Flow Designer. All database objects’ management and settings can be done with the Database Interface Designer, including the generation of type trees.

Type trees can be generated automatically through a wizard for several formats, such as database tables, XML DTDs, enterprise resource planning (ERP) systems, COBOL copybooks, and more. The type trees support grouping, which enables the handling of “nested levels,” as in SWIFT electronic data interchange (EDI) and XML. The type trees also handle validation of data, both input and output, through rules that are associated with the data definitions. We explain the basic concepts of type trees in 3.2, “Type trees” on page 42.

After the generation or creation of the type trees, you validate the type tree. You can do this by using a validation map. See 3.3.5, “Validation maps” on page 84. After your type trees are validated, you can create the maps that transform the data. You start by adding input and output cards to the transformation map, at least one card per physical input and output datastream. You define metadata as being the schema of the card, in which you declare the type tree that represents the metadata of each card and the level within the type tree that is used to describe the data. WebSphere Transformation Extender can handle multiple inputs or multiple outputs (many-to-many, any-to-any). The mapping is a simple process to describe how to generate output data. For each field of each output card, rules can be added in which you can use a simple drag-and-drop method for the types from input cards, mathematical formulas, conversions, literal values, or a concatenation of any or all of these. We describe the basic concepts of maps in 3.3, “Maps” on page 72. After you define your mappings, you can build (compile) a pseudo-executable file that contains all your transformation logic and is interpreted by the transformation server. Compilation must be done specifically for the target platform.

Depending on the target environment, you can use the compiled maps directly, or you might need to create a system. A system is a set of logically related maps or subsystems that represent a transformation unit. The system diagrams show the workflow with its data sources, components, references, servers, and data targets. The Integration Flow Designer is used during development to define and manage the system. We describe the basic concepts of systems in 3.4, “Systems” on page 86.