Processes

Creating a Translation

A translation consists of two parts:

• • Source Process

  • Destination Process (Mapping)

The following is defined on the source Process:

• • Partner

  • Event

  • Source Message Standard

The following is defined on the destination Process:

• • Destination Message Standard

  • Destination File Name

  • Destination Subject (if sent via Email)

  • Destination Email address (if sent via Email)

  • Mappings for each element on the destination Message Standard

Source Process Page

Importing From Test: The ‘Upload file’ option can be selected to upload an existing process, which may or may not include Message Standards.

Level hierarchy version: For legacy purposes. Select 3.

Validate all of message: For legacy purposes. Leave unchecked.

Trim Interchange: Removes anything before the UNB or after the UNZ segments.

Click the ‘New Destination Process’ button to make new mapping. You may map source to more than one destination process. They can be dragged up and down to change the order. Variables used in the earlier ones can be used in the later ones.

Destination Process Page

File Name: Any variables from your mapping can be used in this field, in addition to some standard place holders such as [Date] and [Time].

Email Address: The email address to send the file to, if delivering by email. Variables can be used here.

Email Subject: The email subject, if sending by email. Variables can be used here.

Destination Type: Either:

• • Deliver to a Transport

  • Chain to another process – This can link two processes together. Sometimes this is the easiest approach for some mappings. An example of this would be to flatten a file to a single segment CSV and then chain it to another process which coverts it to the final format.

Send Xml Declaration: When checked this includes the <?xml …?> header for Xml messages.

Mapping Screen

On the mappings tab is where you can create the destination standard:

On the left is the destination Message Standard. Items in the tree will bold if they have a mapping on them.

If they have one or two functions, the functions will show in the tree. If they have 3 or more functions, the tree will just show “3 functions”.

All mappings are performed using functions. The interface provides quick access to these functions through the first three mapping options:

• Data Element:

  • Copy a value directly from the source message

• Literal:

  • Put a literal value into the element

• Variable:

  • Put the value from a variable into the element

Selecting functions allows you to have complete control over the mapping. In this area you can select functions to add to the mapping.

Functions can be chained together by storing the result in Variables, and using the variable as a parameter in the next function.

Variables must be defined in the variable tab.

You may drag the Functions around to change the order.

Each function has parameters, these are the values passed into the function which are used to calculate the result. Parameters come in four types:

• Data Element:

  • A value from the source message

• Variable:

  • A variable used previously in the mapping, or a built in variable

• Field:

  • A value which is used by the Crossfire engine in the mapping process

• Literal:

  • A text value you can specify

For any function, click on the ‘Edit Parameters’ link to modify the parameters.

Repeat Mapping

When selecting a Segment or Segment Group in the mapping window. You have the option to specify which destination segment, this segment will repeat for.

The Crossfire engine will attempt to automatically establish this, but if you find elements are repeating the in correct number of times, you can use this to force it to repeat for a particular element in the source file.

To force an element to repeat a specific number of times, you can use the built in variables:

• • Build.SegmentRepeatCount

  • Build.SegmentGroupRepeatCount

These are typically used in more advanced mapping, as if you use these, it is most likely the same values will just be repeated in the mapping over again.

These can be used in combination with a counter and a conditional function to perform such logic as:

If (Repeat Number = 1) Set Value = A

If (Repeat Number = 2) Set Value = B

Segment Repeating

You can use the following xpath to create a single repeat for multiple source repeats

/SG0/Line[not(OrderNumber=preceding::OrderNumber)]

Functions

There are three types of Functions:

• • TSQL Functions

  • C# Functions

  • Built-in Functions (part of the Crossfire Engine)

All aggregate functions (e.g. Sum, Min, Max, Count) are built in functions. Aggregate functions all require the user to specify the level at which they would like to perform the aggregation. This is done by specifying an [X] in the xPath.

Users can create their own functions using the Functions page in the Work With. Functions can be written in TSQL or C#.

Name: This is used to identify the function

Category: This is used only for categorising purposes.

Description: This is shown on the drop down in the mapping page when selecting the function.

Type: TSQL/C#

Value: The actual TSQL or C# to run.

Return Type: Either ‘String’ or ‘Void’. Void functions do not return values.

Partner: If this function is specific to Partner. Then select the Partner. This function will not show in the drop down for other Partners.

When creating functions, the parameters need to be specified in square brackets []. These will then be replaced when the function runs.

When creating strings in C# functions, they must always be prefixed with the “@”.

Parameters must also be created from the Parameters tab. Uses can select the input types for their Parameters. In most cases this will be all of the Parameter types.

An example of a C# function:

System Tests

The system test page allows users to test their translations. Each translation with a test loaded is shown on the system test page.

Tests can be loaded for both source an destination processes.

When the test is run, it is matched against the expected value and a tick or cross is displayed.

For values such as dates, times, a ‘System test literal’ can be specified on the mapping page to prevent a false positive from being detected.

Note that when a test literal is specified for a data element, none of the functions against that data element will be run. This is to allow for costly operations / those with side effects to be skipped when testing. If these functions need to execute (for example, to set a variable), but you still require a test value for the element, you can use a conditional based on the field Build.IsSystemTest, as shown below.