In this section: |
This topic provides step-by-step instructions on how to configure a basic inbound message flow for the iWay Integration Solution for EDI X12. The message flow represents the movement and tasks in the conversion of a message from Electronic Data Interchange (EDI) format to XML format and acknowledgement of the message.
To access the iWay Service Manager Administration Console, you must first make sure that the iWay Service Manager service is running.
For instructions on starting iWay Service Manager, see the iWay Service Manager User's Guide.
or,
from a browser such as Microsoft Internet Explorer, enter the following URL,
http://host:port
where:
The following image shows the URL with the default values.
Note: The default user name and password is iway.
The iWay Service Manager Administration Console opens, as shown in the following image.
The iWay e-Business Information Exchange (Ebix) framework supplies several Ebix files for the iWay Integration Solution for EDI X12.
An Ebix file for EDI-X12 is named X12_transaction_set.ebx, where transaction_set is the transaction set number. For example, the Ebix file for EDI X-12 transaction set 4050 is named X12_4050.ebx.
For details on the supported EDI-X12 transaction sets, see Ebix-Supported Transaction Sets.
This topic describes how to add an Ebix to the Registry on Windows and UNIX.
The Ebix pane opens, as shown in the following image.
You are prompted for the name of the Ebix and an optional description.
Note: This step must be repeated for each Ebix X12 message set that is added to the Registry.
On the Ebix pane, you will see that the Ebix was successfully added. Later you will associate it with the channel for inbound processing.
Depending on your system configuration, there are two methods that you can use to add an Ebix to the Registry on UNIX.
In iWay Service Manager, a special register is a name-value pair that defines a variable that is carried throughout the system. Once defined, this variable is available to all components of the system. Within the EDI components, a Best Practice is to use special registers to define inputs and outputs. When packages containing channels are migrated between systems, the only changes required to deploy in the new location is to modify these special registers and build the channel. Channels may have many locations and this practice will minimize the effort required to migrate. For a complete list of system special registers that are provided, see the iWay Service Manager Programmer's Guide. For more information on defining a special register of your own, see the iWay Service Manager User's Guide.
The sample inbound channel uses a set of special registers defined as X12. For example:
To add a special register set to your channel:
The Channels pane opens.
The Assign register pane opens.
An inlet defines how a message enters a channel. It typically contains a:
Select File from the Type drop-down list and click Next.
The configuration parameters pane opens.
Parameter |
Value |
---|---|
Input Path * |
sreg(X12.Input) This value is a special register that uses a defined directory in which input messages are received. Make sure that you have created this directory; otherwise, errors will occur during deployment. |
Destination * |
sreg(X12.ListenerOutput) This value is a special register that uses a defined directory in which output files are stored after transformation. Make sure that you have created this directory; otherwise, errors will occur during deployment. |
Removal Destination |
sreg(X12.Archive) This value is a special register that uses a defined directory to which input messages are moved if they fail during transformation. Make sure that you have created this directory; otherwise, errors will occur during deployment. It is recommended to configure a removal destination when you are constructing a basic channel. |
Suffix In |
* Input files with any file extension are allowed. |
Suffix Out |
xml The extension for output files is .xml. |
You are prompted for the name of the listener and an optional description.
The EDIX12SplitterPreParser parses an EDI input file with one or more ISAs and multiple transaction sets (STs), and creates multiple XML output files. One XML output file is produced for each transaction set. You can also use the EDIX12SplitterPreParser if there is only one transaction set in an ISA.
For details on the supported EDI-X12 transaction sets, see Ebix-Supported Transaction Sets.
The Preparsers configuration parameters pane opens.
The following table lists and describes the available configuration parameters for the preparser:
Parameter |
Description |
---|---|
Template |
Used to locate the template in the Ebix used in the transformation from EDI format to XML format. |
Debug |
If enabled, the transformation components are written to files in the local directory. This parameter is set to False by default. |
Segment Terminator |
The control character that marks the end of a specific variable-length segment. To view a list of segment terminator characters, see Separators and Terminators. |
Element Delimiter |
The control character used to separate elements in a segment. It follows the segment identifier and each data element in a segment except the last. To view a list of element delimiter characters, see Separators and Terminators. |
Component Element Delimiter |
The control character used to separate sub-elements/components in a composite element. To view a list of component element delimiter characters, see Separators and Terminators. |
Escape Character |
The escape character is necessary if any of the EDI document separators is part of the actual value of an attribute. |
Timestamp |
Disabled by default, this option writes a timestamp to the log file. When enabled, the log file will display the start and end time of the file transformation and the input file name that is used. This feature is useful in development or debugging environments when processing batches of files. When the transaction log is not in use (for example, in a production mode) then this information is available in the Activity Log. Note: To use this feature, logging must be enabled in the Log Settings section of the iWay Service Manager Administration Console. |
XML Transformer |
Enabled by default, this parameter sets the EDIX12SplitterPreParser to transform the individual documents that are split from the incoming message into XML format. Note: Use the standalone EDI batch splitter preparser (com.ibi.preparsers.XDEDIBatchSplitter) if you do not require an XML transformation to be called. |
Insert Group Loop |
Inserts a group loop tag in the XML document. Group loop tags are displayed in activity logs and validation processing reports. Note: Ensure that this parameter is set to false. By default, this parameter is set to true. |
Node 'delimiters' |
If set to true, node delimiters are added to the generated XML document. By default, this parameter is set to false. |
For example, if the message type of the EDI input document is 810, and the version is 004050, the constructed template name is X12_810_004050toXML.xch.
You are prompted for a name and optional description for the new preparser.
Now that you have added a File listener and splitter preparser to the Registry, you are ready to add and define an inlet. You will associate the previously created listener and preparser with the inlet.
Parameter |
Value |
---|---|
Name * |
EDItoXML_Inlet |
Description |
Inlet for EDI to XML |
The next pane prompts you for the component type.
The next pane prompts you to select a listener.
The listener is associated with the inlet. Now you need to associate the preparser created earlier with the inlet.
The next pane prompts you for the component type.
On the next pane, you are prompted to select a preparser.
You have now successfully completed definition of the inlet.
For this sample channel configuration, you will define a route that will invoke the X12 to XML validation process flow. The outcome of the validation process flow will place valid transformed XML data in a defined output folder. Invalid transformed data will be routed to an errors folder. An X12 functional acknowledgement and a validation report will be sent to their designated output folder defined in the sample channel.
This section describes how to create a validation process flow using iIT Designer and bind it to a sample inbound channel as a route.
To create a new project and start the process flow using iIT Designer:
The New Process Flow Wizard opens, as shown in the following image.
In the Description field, type a brief description (optional).
The new x12toXML_pflow_AckRpt node appears under the Flows folder, and the workspace displays a Start and End object with a relation established in between, as shown in the following image.
You are ready to build the x12toXML_pflow_AckRpt validation process flow by configuring objects to it and specifying their relationships.
To configure objects for the process flow using iIT Designer:
The New Service Object dialog box opens.
The Service Object Type wizard opens.
The new Service object (X12_Validation_Rpt) appears in the workspace.
The Relation Properties wizard opens.
This option indicates that there are no conditions that affect the path, and that the path between the two objects will always be followed.
A line appears between the objects to indicate that a relationship has been established, as shown in the following image.
The File Type dialog box opens.
The File Type dialog box opens.
The new File object (Write_Validation_rpt) appears in the workspace.
The Line Configuration dialog box opens.
A line appears between the objects to indicate that a relationship has been established.
The End Name and Description dialog box opens.
The End Name Schema dialog box opens.
The Relation Configuration wizard opens.
A line appears between the objects to indicate that a relationship has been established, as shown in the following image.
The Relation Configuration wizard opens.
A line appears between the objects to indicate that a relationship has been established, as shown in the following image.
The New Service Object dialog box opens.
The Service Type dialog box opens.
The Properties dialog box opens. The configuration parameters for EDIX12AckAgent are displayed. The following table lists and describes the configuration parameters.
Parameter |
Description |
---|---|
Protocol |
Protocol on which to make acknowledgment copies. Select one of the following options from the drop-down list:
|
Location |
Location for acknowledgment copies. |
End Tag |
The surrounding XML tag. |
Preemitter |
Determines whether the preemitter should be run on acknowledgment output. |
Error |
Determines whether to send an error. |
ISA Control Number |
Element location of ISA control number. Select one of the following locations from the drop-down list:
|
GS Control Number |
Element location of GS control number. Select one of the following locations from the drop-down list:
|
ST Control Number |
Element location of ST control number. Select one of the following locations from the drop-down list:
|
Stream Acknowledgment |
Determines the level of acknowledgment information to return. Select one of the following acknowledgment levels from the drop-down list:
|
The new Service object (X12AckAgent) appears in the workspace.
The Line Configuration dialog box opens.
A line appears between the objects to indicate that a relationship has been established.
The New File Object wizard opens.
The File Object Type wizard opens.
The Object properties wizard opens.
The new File object (Write_Ack) appears in the workspace.
A line appears between the objects to indicate that a relationship has been established, as shown in the following image.
The End Name and Description dialog box opens.
The End Object Schema wizard opens.
The new End_Ack object appears in the workspace.
The Relation Configuration wizard opens.
A line appears between the objects to indicate that a relationship has been established.
The Relation Configuration wizard opens.
The Relation Configuration wizard opens.
A line appears between the objects to indicate that a relationship has been established.
The New Decision Switch Object wizard opens.
XPATH(count(//documents/ValidationReport/Report/Success))
This will check if the validation report is successful or not. If the validation report returns a success node, then the incoming data will go to the Good File write. Otherwise, it will go with the error route to write the error file write.
You can delete default empty and null cases from the cases list.
The following image shows the Switch Cases configuration wizard showing the two cases (1 and 0) in the switch cases list.
The new Decision Switch case object appears in the workspace.
A line appears between the objects in the workspace to indicate that a relationship has been established.
The Service Object Type wizard opens.
com.ibi.agents.XDXMLExtract
Note: This is not the xpath function.
The Relation Configuration wizard opens.
A line appears between the Decision Switch and XDXMLExtract objects to indicate that a relationship has been established.
The Relation Configuration wizard opens.
All cases except case 1 should have been selected.
A new relation line appears between the Decision Switch and XDXMLExtract1 objects to indicate that a relationship has been established, as shown in the following image.
The Service Object Type wizard opens.
'<output>','</output>'
“‘”
The XDDocUpdate object appears in the workspace.
The New File Object wizard opens.
The File Object Type wizard opens.
The Object properties wizard opens.
sreg(X12.GoodOutput)
sreg(basename)_*.xml
The new File object (Good File) appears in the workspace.
The New File Object wizard opens.
The File Object Type wizard opens.
The Object Properties wizard opens.
sreg(Hipaa.BadOutput)
sreg(basename)_*.xml
The new File object (Bad File) appears in the workspace.
The Junction object appears in the workspace.
A copy of the Junction object (junction1) appears in the workspace.
The Relation Configuration wizard opens.
A relation (line) appears between Good File and the Junction object.
The Relation Configuration wizard opens.
A line appears between the objects to indicate that a relationship has been established, as shown in the following image.
The Relation Configuration wizard opens.
A relation (line) appears between Good File and the Junction1 objects.
The Relation Configuration wizard opens.
A relation (line) appears between Bad File and the Junction1 objects, as shown in the following image.
The End Name and Description properties wizard opens.
The End Object Schema wizard opens.
The new End object appears in the workspace.
A new Relation (line) appears between the Junction object and the End object, as shown in the following image.
The End Name and Description properties wizard opens.
The End Object Schema wizard opens.
The new End2 object appears in the workspace.
A new Relation (line) appears between the Junction1 object and the End2 object, as shown in the following image.
The process flow is now complete.
Now you need to validate the process flow and publish it to the Registry of the iWay Service Manager Administration Console for use in the route of a channel for outbound processing.
Validating a process flow ensures that its structure is correct. Publishing a process flow makes it available in the Registry for use in a channel configuration. For instructions on validating and publishing the process flow, see the iWay Integration Tools Designer User's Guide.
Your next step is to add a new route to the Registry using the iWay Service Manager Administration Console and associate the process flow with it.
To define a route and associate the process flow with It:
Parameter |
Value |
---|---|
Name * |
EDItoXML_Route |
Description |
This route will invoke the X12 to XML validation process. The outcome of this process will place valid X12 transformed data in your valid inbound folder. Invalid X12 transformed data will be routed to its appropriate folder. A validation report will also be generated and sent to its appropriate folder. |
You are prompted for the type of component to associate with the route.
The route, with its associated process flow, has been successfully defined.
An outlet defines how a message leaves a channel. An emitter is a transport protocol that sends a document to its recipient. In the sample configuration, we will use a File emitter. For details on supported protocols, see the iWay Service Manager Protocol Guide.
For the channel in this example, you will add one emitter to the Registry. Then you will define one outlet and associate the emitter with this outlet.
When you associate the outlet with the channel in later steps, you will apply a condition to dynamically direct the flow of the output document based on its content.
In the example, you will add an emitter for the acknowledgement data. In the example, the data for the functional acknowledgement (transaction 997) is in EDI flat file (non-XML) format. When you add the acknowledgement outlet to the channel, you will set the condition _isFLAT(). This condition tests the output data for flat file (non-XML) format. If the data is in flat file (non-XML) format, it is routed to the specified destination.
The configuration parameters pane opens.
Parameter |
Value |
---|---|
Destination * |
sreg(X12.Ack)/SREG(basename)*.txt This value is the directory where the acknowledgement output is placed. You can use an extension other than .txt, for example, .edi or .data. sreg(X12.Ack) is a special register value that uses a defined directory in which output files are stored after transformation. Make sure that you have created this directory; otherwise, errors will occur during deployment. On output, an asterisk (*) in the destination file name is replaced by a date and time stamp. For details on the special register (SREG) used in the preceding file name, see the iWay Service Manager User's Guide. |
Create Directory |
false |
Parameter |
Value |
---|---|
Name * |
Ack_Out_Emitter |
Description |
Emitter for acknowledgement output for EDI. |
Parameter |
Value |
---|---|
Name * |
EDI_Ack_Outlet |
Description |
Acknowledgement outlet for EDI. |
The next pane prompts you to select an emitter.
Now you have defined the two outlets.
Now that you have defined the inlet, route, and outlets for the channel, you are ready to add the channel to the Registry and associate the conduits with it.
Parameter |
Value |
---|---|
Name * |
EDItoXML_Channel |
Description |
Channel for EDI to XML inbound processing. |
You are prompted to associate components with the channel.
The inlet is added to the channel. Now you need to associate the route defined earlier with the channel.
The next pane prompts you for the component type.
On the next pane, you are prompted to select a route.
The Set Condition pane opens.
This condition tests the output data for EDI flat file (non-XML) format. If the data is in EDI flat file (non-XML) format, it is routed to the destination specified when you added the emitter for acknowledgement output.
The Channel Definitions pane opens.
The Channel Definitions pane opens.
Now that you have associated all the components with the channel, you are ready to build it.
The results of the build are displayed on the right pane.
If an error or errors are displayed in the Message column, take the appropriate action as instructed.
Deployment is the mechanism by which a channel moves from being stored in the Registry to becoming active in iWay Service Manager. For more information on deployment, see the iWay Service Manager User's Guide.
The Channel Management pane reopens.
The red X under Status changes to a green check mark to indicate that the channel has been started. If an error or errors are displayed, take the appropriate action as instructed.
To ensure that the channel is working as expected, perform the following steps.
For more information on obtaining EDI X12 sample files for testing purposes, see Extracting SWIFT User Samples.
For example, if you specified the destination file name for the XML emitter as _SREG(basename)_*.xml per the configuration example, an EDI input file named X12856C001_4050.x12 is named _X12856C001_4050_2008-03-03T19_33_26.684Z.xml on output.
Using the Archive Manager feature of iWay Service Manager, you can archive your channel configuration with its associated components and import them into another Registry. They will then be available from that Registry for modification or reuse.
For details on this feature, see the iWay Service Manager User's Guide.
iWay Software |