This section describes how to create a PIMO using Business Object Designer. Before proceeding, review the previous sections of this chapter, and make sure you have access to the Swift User HandBook and Business Object Designer, with which you should be familiar. For more information, see the Business Object Development Guide. You should also have access to Map_Objects.txt, which contains the PIMOs shipped with this release as well as thousands of sub-maps and objects that may be of use.
This provides access to your repository. To load the repository, see Installing and configuring the connector and the system installation guide for your operating environment.
This displays the New Business Object Dialog.
Map_Swift_MT<SourceNN>_to_MT<DestinationNN>
where SourceNN is the SWIFT message type number that corresponds to the business object you want to transform and DestinationNN is the SWIFT message type number that corresponds to the destination business object. This is the name of a new PIMO representing the mapping between the source message type and the destination message type as shown in Figure 22.
The type syntax for the Port is as follows:
PimoName_Port
In the example shown in Figure 23, the type is as follows:
Map_Swift_MT520_to_MT540_Port
The Port object must have two child objects, IPort and OPort, which correspond to the business objects representing the source and destination SWIFT messages.
The type syntax for the IPort is as follows:
Swift_<IPortSourceNN>
In the example shown in Figure 24 the IPort type is Swift_MT520.
In the example shown in Figure 24 the OPort type is Swift_MT540.
A Declaration object at the top-level of a PIMO specifies high-level variables as required by Action objects at this level. As shown in Figure 25, the Declaration variable applies to the top-level Action object discussed below in "Defining action". Following the naming convention for a Declaration object, the type of this variable is Map_Swift_MT520_to_MT540_Declaration.
In the example, the Declaration type is Map_Swift_MT520_to_MT540_Declaration
Figure 25. Specifying a Declaration for a Top-Level PIMO
For examples of sequence- and field-level Declarations, see "Representing sequence objects" and "Representing field objects".
To define the top-level Action Object for the PIMO:
In the example, the Action type is Map_Swift_MT520_to_MT540_Action, as shown in Figure 26.
To create all other Action objects for a PIMO mapping SWIFT MT520 to MT 540, you must become familiar with the actual tag- and field-level maps for these messages. This information is available in the SWIFT User Handbook, Category 5, Securities Markets Message Usage Guidelines. The PIMO models the SWIFT tag and field maps.
The sections below describe how to extract this information and create Action objects that represent SWIFT sequences and fields.
Review the maps in the SWIFT User Handbook, Category 5, Securities Markets Message Usage Guidelines Appendix for SWIFT MT520 to MT 540 and identify the following:
Use the following naming convention for representing a sequence in a PIMO:
Map_Swift_MT<SourceNN>_<X>_to_MT<DestinationNN>_<X>
where X stands for the sequence letter and is always in uppercase.
Map_Swift_MT<SourceNN>_to_MT<DestinationNN>_<X>
As shown in Figure 27, the child objects representing some of the sequences make use of Delegate Action because the mapping requires multiple Compute Action objects.
Figure 27. Specifying sequence objects with delegate action
When using Delegate Action, you must pass the IPort and OPort object paths. For example, Figure 27 shows that mapping computations from Swift_MT520_A (the child object of Swift_MT_520Data) to Swift_MT540_A (the child object of Swift_MT_540Data). Accordingly, the naming convention is as follows:
IPort.<Source_Object_Path> OPort.<Destination_Object_Path>
In the example, the corresponding entries are:
IPort.Swift_MT520Data.Swift_MT520_A OPort.Swift_MT540Data.Swift_MT540_A
For each delegated sequence shown in Figure 27, you must define the Port, Declaration, and Action objects for the parent. Declaration is mandatory at the level of any Compute Action that refers to variables. Figure 28 shows how some of the Action and sub-Action objects are defined.
Figure 28. Sub-action objects for a sequence object
Just as SWIFT sequences can contain other sequences as well as field tags, sequence objects in PIMOs make reference to sequence and field objects. Field objects are child objects of sequence Action objects. This section describes how to create field objects that map to other field objects via parent sequence Action objects.
The previous section showed how to define sequence objects, including Map_Swift_20_to_20C. Figure 29 shows how to create the PIMO entries that correspond to the field and sub-field mapping for this sequence.
Figure 29. Field action objects for a sequence
As shown in Figure 29, you must specify Port (IPort and OPort) objects, Declaration variables, and Actions for Field objects:
Port The type for IPort and OPort is the source and destination tag, stripped of tag letters. In this case, they are the same, Swift_Tag_20. IPort, by convention is Key (IsKey = true).
Declaration The tag letter variable is specified as Letter. In this example, the default value is C. The keyword final designates this variable as a constant, and, by convention, the first variable is Key (IsKey = true). Qual_<QUALIFIER> represents the qualifier. (The qualifier is always in uppercase.) In the example the default value is SEME.
Action The sub-Action objects are as follows:
Action1 type=compute;opCode=move;target=OPort.Letter;Letter The value of the Letter variable is moved to the Letter attribute of OPort (which is Swift_Tag_20)
Action2 type=compute;opCode=move;target=OPort.Qualifier;Qualifier The value of the Qualifier variable is moved to the Qualifier attribute of OPort (which is Swift_Tag_20).
Action3 type=compute;opCode=move;target=OPort.DataField.Swift_20_C.Reference; IPort.DataField.Swift_20.TransactionReferenceNumber The value of IPort.DataField.Swift_20.TransactionReferenceNumber is moved to OPort.DataField.Swift_20_C.Reference.
Figure 30 shows a field map that involves code word mapping and a Delegate Action.
Figure 30. Field mapping with code words
For Action3, the Delegate Action, you must define the Port (IPort and OPort) Declaration, and sub-Action objects as shown in Figure 31.
Figure 31. Code word declaration for a field map
The code words are declared and assigned constant default values. A Scenario Action (Action6) specifies an equality boolean expression and a contingent Compute Action to execute if the expression evaluates to false.