• No results found

Overview

The BWEDI-Sample project associated with TIBCO ActiveMatrix BusinessWorks Plug-in for EDI installation demonstrates the use of the plug-in. It is located in the EDI_HOME\examples directory.

The project includes one CallBack shared resource, and the following processes:

• Instream-Translator Process

• InstreamWithCallBack Process

The two processes listed above use the same input file. Therefore, in File output mode, in order to avoid an error indicating that the output files already exist, run one of the processes, then move the output files to an appropriate location before you run the other process.

Set Up the BWEDI-Sample Project

|

39

Set Up the BWEDI-Sample Project

To set up this sample project, complete the following tasks:

Task A Open the Project

Complete the following steps to open the BWEDI-Sample project:

1. Start TIBCO Designer.

2. Click the Open Existing Project button.

3. Click the button in the Open Project dialog to locate the sample project, then click the OK button.

The project appears, as shown in Figure 21.

Figure 21 BWEDI-Sample Project in TIBCO Designer

Task B Test Each Process of the BWEDI-Sample Project Complete the following steps to ensure the process works properly:

1. Check if all the global variables point to the correct directories.

The project contains two user-defined global variables: InputFolder and OutputFolder. The value of the InputFolder global variable indicates from which input files are taken. The value of the OutputFolder global variable indicates to which output files are written, as shown in Figure 22.

40

|

Chapter 4 Using the Sample Project

Figure 22 BWEDI-Sample: Global Variables

See Defining Global Variables on page 35 for details about how to edit global variables.

2. Select the process definition you wish to test in the project panel.

3. Click the Tester tab on the left side of the project panel.

4. Click the button to test the process.

The input data used in this sample project are available under the DemoData folder in the TIBCO Foresight Instream and TIBCO Foresight Translator’s installation home (the directory defined in the InputFolder global variable).

Guidelines, schemas, and map files, including the source guidelines and target guidelines specified in a map file, should be under the Database folder in the TIBCO Foresight Instream and TIBCO Foresight Translator’s installation home, for example, the TIBCO_FORESIGHT_HOME\instream-translator\Database directory.

Instream-Translator Process

|

41

Instream-Translator Process

This process demonstrates how the Validation, Document Splitter, and Translation functions work together to process an inbound EDI.

Figure 23 Instream-Translator Process

Input

The following are process inputs:

• the 837Iclean.txt input EDI file.

• the 837AQ320 guideline.

• the DEMO3_EDI_to_XML_837I map file.

Output

The following are process outputs:

• the 837Iclean_detail_result.txt validation result file.

• the 837Iclean_summary_result.txt validation summary file.

• the 837Iclean_ds_report.xml Document Splitter report file.

• the 837Iclean_ds_valid_00001.txt validate EDI file.

• the 837Iclean_ds_valid_00001_XML.xml translated file.

Activities

There are two activities involved in this process:

• Instream Activity

• Translator Activity

42

|

Chapter 4 Using the Sample Project

Instream Activity

The Instream activity:

1. Validates the input EDI

2. Creates detail and summary results

3. Generates a file including the valid EDI using the Document Splitter function of the Instream activity. (The input EDI data has no invalid data, there is no invalid file generated in this case.)

Table 15 shows the configuration of the Instream activity.

Table 15 Set Up the Instream Activity for the Instream-Translator Process

Field Input

output_directory OutputFolder (For example, C:\output)

Instream-Translator Process

|

43

Figure 24 shows the output of the Instream activity.

Figure 24 Instream-Translator Process: Output of the Instream Activity

Translator Activity

The Translator activity translates the valid EDI generated by the Instream activity to XML format.

Table 16 shows the configuration of the Translator activity.

Table 16 Set Up the Translator Activity for the Instream-Translator Process

Field Input

Configuration

Name Translator

Input Mode File

Output Mode File

Operation Type EDItoXML

Input

map_filename DEMO3_EDI_to_XML_837I

44

|

Chapter 4 Using the Sample Project

Figure 25 shows the output of the Translator activity.

Figure 25 Instream-Translator Process: Output of the Translator Activity input_file The output of the Instream activity (ds_rpt_valid_filename).

output_directory OutputFolder (For example, C:\output) Table 16 Set Up the Translator Activity for the Instream-Translator Process (Cont’d)

Field Input

InstreamWithCallBack Process

|

45

InstreamWithCallBack Process

The InstreamWithCallBack process has an Instream activity with a CallbBack shared resource enabled. This CallBack shared resource allows you to change guidelines, profiles, and implement different business logic by modifying codes.

Figure 26 InstreamWithCallBack Process

Input

The following are process inputs:

• the 837Iclean.txt file.

Output

The following are process outputs:

• the 837Iclean_detail_result.txt validation result file.

• the 837Iclean_summary_result.txt file.

Activity

There is only one activity in this process: the Instream activity.

46

|

Chapter 4 Using the Sample Project

Table 17 shows the configuration of the Instream activity.

Figure 27 shows the output of the Instream activity.

Figure 27 InstreamWithCallBack Process: Output of the Instream Activity Table 17 Set Up the Instream Activity for the InstreamWithCallBack Process

Field Input

Configuration

Name Instream

Input Mode File

Output Mode File

CallBack Check this checkbox to enable the CallBack function.

CallBack SharedResource Click the button to locate the CallBack resource.

Input

input_file TIBCO_FORESIGHT_HOME\Instream-Translator\837Iclean.txt

output_directory C:\output\

Deploy the BWEDI-Sample Project

|

47

Deploy the BWEDI-Sample Project

To configure and deploy this sample project, complete the following tasks:

Task A Build a BWEDI-Sample Enterprise Archive (EAR) in TIBCO Designer To create the EAR file in TIBCO Designer, complete the following steps:

1. Select Tools > Create Project EAR from the menu bar.

2. Select the Process Archive resource in the BWEDI-Sample Enterprise Archive you created in step 1. In the Processes tab, click the button to specify the process definitions you want to include, as shown in Figure 28.

Figure 28 Add a Process Starter to the Archive

3. Click the Apply button.

4. Repeat steps 2 and 3 to add other processes if required.

5. Click the Build Archive button in the BWEDI-Sample Enterprise Archive panel to create the Enterprise Archive (EAR) file, as shown in Figure 29.

Figure 29 Build Archive

48

|

Chapter 4 Using the Sample Project

6. Click the OK button in the Note dialog.

The BWEDI-Sample.ear file is generated by TIBCO Designer, which you can then deploy from TIBCO Administrator.

7. Save the project.

Task B Deploy the BWEDI-Sample Project in TIBCO Administrator To deploy the project in TIBCO Administrator, complete the following steps:

1. Select Start > All Programs > TIBCO > TIBCO Administrator

version_number > TIBCO Administrator to start TIBCO Administrator.

2. Select a domain and log in.

3. Select the Application Management folder, as shown in Figure 30.

Figure 30 Create New Application in TIBCO Administrator

4. Click the New Application button on the Application Management panel.

5. Click the Browse button to locate the EAR file, then click the OK button in the Before starting TIBCO Administrator, make sure TIBCO Hawk Agent and TIBCO Administrator services have been started.

Deploy the BWEDI-Sample Project

|

49

7. Click the Deploy button, as shown in Figure 31.

Figure 31 Deploy the Application in TIBCO Administrator

8. Click the OK button in the Deploy Configuration panel.

The application is deployed successfully, as shown in Figure 32.

Figure 32 Deploy Successfully

Task C Start the BWEDI-Sample Project in TIBCO Administrator To start the project in TIBCO Administrator, complete the following steps:

1. In the tree on the left side of the TIBCO Administrator page, expand the Application Management > BWEDI-Sample folders, and select the Service Instances item, as shown in Figure 33.

Figure 33 Application Management

50

|

Chapter 4 Using the Sample Project

2. Select a service instance and click the Start button to start the process, as shown in Figure 34.

Figure 34 BWEDI-Sample Service Instance

The process starts successfully and indicates "Running" in the State column.

|

51

Appendix A Electronic Data Interchange

This appendix provides a basic introduction of Electronic Data Interchange (EDI).

Topics

• Overview, page 52

• Structure, page 53

• Standards, page 55

52

|

Appendix A Electronic Data Interchange

Overview

Electronic Data Interchange (EDI) is a standardized messaging framework developed by industry groups for exchanging information between trading partners in a structured, predetermined format.

Structure

|

53

Structure

An EDI file contains a structure known as enveloping. Enveloping is the way EDI ensures file integrity and lets the message determine its destination and type.

Figure 35 shows an X12 EDI structure example.

Figure 35 EDI Structure Interchange Header (ISA)

Interchange Trailer (IEA)

Functional Group Header (GS)

Functional Group Trailer (GE) Transaction Set Header (ST) Data Segments Transaction Set Trailer (SE)

Transaction Set Header (ST) Data Segments Transaction Set Trailer (SE)

...

54

|

Appendix A Electronic Data Interchange

The following list contains details about Figure 35:

• The interchange is the basic unit of an EDI file. Several interchanges can be bundled into a single file for data transfer.

An interchange starts with an interchange header (ISA) and ends with an interchange trailer (IEA).

• A functional group is a group of similar transaction sets which have the same functions.

A functional group starts with a function group header (GS) and ends with a functional group trailer (GE).

• A transaction set contains the information required by a receiver to perform a standard business transaction.

A transaction set starts with a transaction set header (ST) and ends with a transaction set trailer (SE).

• Data segments are used to make up transaction sets. Data segments are roughly equivalent to a single line on a document. Data elements contain the basic units of information and are used in various combinations to make up data segments.

Standards

|

55

Standards

EDI standards (protocols) help facilitate EDI by providing a common format or rules of data structure and transmission protocols. The objective is to use an agreed upon structure for communicating the data in business documents. Each organization that maintains a set of standards provides a full set of

documentation and definitions of each version of their standards.

The following are brief introductions to some of the standards:

X12

X12 standards are EDI standards developed by the Accredited Standards Committee (ASC) X12. The ASC X12 are chartered by the American National Standards Institute (ANSI).

In the X12 standard, a transaction set contains the data for a well defined business function (for example, a purchase order). Today, there are more than three hundred X12 transaction sets used by more than thirty thousand organizations for nearly every facet of business-to-business operations.

HIPAA

The Health Insurance Portability and Accountability Act (HIPAA) is a specific set of messages based on the X12 standard, which is used for healthcare-related information exchange.

EDIFACT

EDIFACT stands for Electronic Data Interchange for Administration, Commerce, and Transport. EDIFACT refers to a set of international standards, directories, and guidelines for the electronic interchange of structured data between separate computer systems. The EDIFACT standards are supported by the United Nations Economic Commission for Europe (UN/ECE).

Flat File

Flat File standards are used to validate Flat File data.

XML

XML standard is used to validate XML data and to create HTML reports of validation results.

56

|

Appendix A Electronic Data Interchange

|

57

Appendix B Acknowledgements

This appendix provides a brief introduction of the Acknowledgements supported by TIBCO ActiveMatrix BusinessWorks Plug-in for EDI.

Topics

• Overview, page 58

• Acknowledgements, page 59

58

|

Appendix B Acknowledgements

Overview

Acknowledgements are used to give feedback to the sender of a transaction on the status of the acceptance of the transaction by its recipient. For X12,

acknowledgements such as 997 and 999 are used to provide feedback to trading partners on the validation success or failure of transactions they have sent. For EDIFACT, the CONTRL acknowledgement is used for this purpose. For HIPAA, there are acknowledgements used in the health care industry to report on the validation success or failure of business level application edits. These

business-level acknowledgements are the 277 Unsolicited Health Care Claim Status Notification (277 U), 277 Claim Acknowledgement (277CA), and the 824 Application Advice.

Acknowledgements

|

59

Acknowledgements

The following section lists a brief description of the acknowledgements used by X12, HIPAA, and EDIFACT:

227CA/U Acknowledgements

The 277 Claim Acknowledgement (277CA) is sent by a payer in response to an 837 to report on whether the pre-adjudication validation found them acceptable for adjudication.

The 277 Unsolicited Health Care Claim Status Notification (277U) reports the results of an application system's data content edits on the claims in a transaction set.

824 Application Advice

The 824 Application Advice (824) reports the results of an application system’s data content edits of a transaction set. Editing transaction sets results can be reported at the functional group and transaction set level, in either coded or free-form format.

997 Functional Acknowledgement

The Functional Acknowledgement (997) describes the syntax-level

acknowledgement of the receipt of an X12 functional group. It tells a sender that a receiver has received EDI transactions successfully.

The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical analysis of the electronically encoded documents. The encoded documents are the transaction sets (which are grouped in functional groups) used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.

999 Implementation Acknowledgement

The Implementation Acknowledgement (999) was first available in the X12 004061 subrelease. It is used for reporting the status of implementation guide syntax edits.

60

|

Appendix B Acknowledgements

The transaction set can be used to define the control structures for a set of acknowledgments to indicate the results of the syntactical and relational analysis of electronically encoded documents, based on a full or implemented subset of X12 transaction sets. The encoded documents are the transaction sets (which are grouped in functional groups) used in defining transactions for business data interchange. This standard does not cover the semantic meaning of the information encoded in the transaction sets.

TA1 Interchange Acknowledgement

An Interchange Acknowledge segment (TA1) is a delivery acknowledgement. It reports the receipt of the contents of one interchange control header and trailer envelope in which the envelope surrounds one or more functional groups. The TA1 reports the results of the syntactical analysis of the interchange control header and trailer. Each interchange exchanged between trading partners may contain interchange-level control segments (TA1s) related to prior interchanges.

CONTRL Document (EDIFACT Responses)

When EDIFACT documents are exchanged between trading partners, an acknowledgement of the receipt and syntactical validation of the document can be returned to the sender of the document.

When exchanging EDIFACT documents, the CONTRL document is used to syntactically acknowledge or reject, with error indication, an interchange, group, or message received from a trading partner.

Note that CONTRL is the only message for acknowledgement in EDIFACT.

In contrast, in ANSI X12 there are two messages used for acknowledgement: TA1 and 997/999 Acknowledgement.

Use of a CONTRL message for acknowledging receipt of an interchange, group, or message is not required in EDIFACT. The use of CONTRL is by trading partner agreement.

Parsing Data from XML Format to Hashmap

|

61

Appendix C Parsing Data from XML Format to Hashmap

This appendix shows how the CallBack Java code parses the data in XML format to a Hashmap with keys and values.

Topics

• Overview, page 62

• Parsing from XML to Hashmap, page 63

62

|

Appendix C Parsing Data from XML Format to Hashmap

Overview

The CallBack shared resource allows you to modify the Java code to implement different business logic. It also provides a way, through the updateAnalysis()

method in the code, to parse the info variable value in XML format and form a Hashmap with keys and values.

Figure 36 shows a sample of the info variable value in XML format for the EDI input data and the Flat File input data.

Figure 36 The Info Variable Value in XML Format

Parsing from XML to Hashmap

|

63

Parsing from XML to Hashmap

This section explains the principle behind forming a Hashmap with keys and values from the info variable value in the XML format:

• EDI input data

Each key of the Hashmap corresponds to a combination of the XML parent node and child node. Figure 37 provides a sample screen of the info variable value in the XML format, and the formed Hashmap with keys and values.

In the figure, "Info" is the parent node to the "Interchange" and

"FunctionalGroup" nodes. The "SenderQualifier" node, "Sender" node, and so on, are the child nodes of the "Interchange" node. To specify the sender information key in a Hashmap, combine the parent nodes and the child nodes:

Info.Interchange.Sender. Its value corresponds to the value in the "Sender"

node: 9012345720000.

Figure 37 Parsing EDI Data

The Type key is an extra key in the Hashmap, which is used to demonstrate the input data format. For the EDI input data, the value of the Type key is EDI.

64

|

Appendix C Parsing Data from XML Format to Hashmap

• Flat File input data

Each key of the Hashmap corresponds to a combination of the XML parent node and child node. Figure 38 provides a sample screen of the info variable value in the XML format, and the formed Hashmap with keys and values.

In the figure, "Info" is the parent node, and "Field02" is the child node. To specify the message group information key in the Hashmap, combine the parent node and the child node: Info.MessageGroup. Its value corresponds to the value in the "Field02" node: TEXT.

Figure 38 Parsing Flat File Data

The Type key is an extra key in the Hashmap, which is used to demonstrate the input data format. For the Flat File input data, the value of the Type key is FLAT.

|

65

66

|

Index

S

Separator Group 23 support, contacting xv

T

technical support xv

TIBCO ActiveMatrix BusinessWorks 28 TIBCO Designer 28

TIBCO Foresight 2

TIBCO Foresight Instream 2 TIBCO Foresight Translator 3 TIBCO_HOME xiii

Translation 3, 3 Translator activity 22

V

Validation 2, 11 Validator profile 16

X

X12 55 XML 55

Related documents