In LANSA Composer, as by any other means, there may be a wide variety of steps necessary for a successful transaction document processing solution.  This section summarizes some of the major steps and considerations:

1.  Review and revise LANSA Composer system configuration

Review and revise your LANSA Composer system settings if necessary.  Make sure that you have a fully-functioning LANSA Composer system before you begin to implement a transaction document processing solution.

2.  Review and revise document types and standards

Review the existing document types and document standards, creating new ones or revising the existing definitions to suit your implementation.

Remember:

• The DISCOVER_DOC activity uses the file extension associated with a Document type to determine the document type associated with a transaction document.
• The TXDOC_INBOUND and TXDOC_OUTBOUND processes use the inbound and outbound processing sequences associated with the document type to perform further processing of the document.

Remember:

• For EDI documents, the DISCOVER_EDI activity uses the match agency and match version values associated with each document standard to identify the LANSA Composer document standard definition that applies to the EDI transaction document
• For EDI documents, the DISCOVER_EDI activity uses the SEF file name specified for the document standard to perform EDI validation, if required.

3.  Create inbound and/or outbound transformation maps

Having identified the document types, standards and transaction types that your implementation is required to support, you will need to create transformation maps that can map between the transaction data and your staging database or your application database, according to the approach you have chosen.

Remember that in the standard inbound and outbound process, the transformation maps are assumed to have a basic structure (to the extent that it affects the parameters they receive).  Refer to Model Transformation Maps for Transaction Document Processing for more information.

If you exchange the same transaction types with more than one trading partner, you should start with the objective of re-using the same transformation maps for each trading partner to whom it applies.  There may be cases however where this is not possible or appropriate.  Through its trading partner Linked Maps feature, LANSA Composer supports either possibility.

Remember:

• LANSA Composer uses the map direction, standard and transaction type specified in the data interchange attributes for a transformation map (along with information specified when the map is linked to a trading partner) to identify the transformation map that applies to a transaction document in the FIND_TPMAP activity.
• The inbound process and outbound process reference the import and export processors associated with a transformation map (if applicable) by referencing the corresponding Transformation Map built-in variable and/or by means of the DISCOVER_MAP activity

4.  Create trading partner definitions and transport configurations

You will need to create trading partner definitions for each trading partner with whom you exchange transaction documents.  The trading partner definitions are crucial to the operation of the transaction document framework, as supplied.  You may also need to create configurations (for example FTP inbound or outbound configurations) according to the transport protocols you have agreed with each trading partner.

You can enter basic contact details for each trading partner, although this is mainly for documentary purposes.  Much more important to the transaction document processing framework are the data interchange attributes, linked directories, maps and configurations and the outbound numbering.

Remember:

• For EDI documents, the DISCOVER_EDI activity uses several of the data interchange attributes to identify the interchange trading partner definition that corresponds to values in the EDI document.
• The inbound and outbound processes use the linked directories associated with the trading partner (using the built-in variables) to determine directories used to receive and process inbound documents and to prepare and send outbound documents and for archiving completed inbound or outbound documents.
• The linked configurations may be used (via the built-in variables) to execute the particular transport arrangements agreed with the trading partner.
• LANSA Composer uses the transformation maps linked to a trading partner (along with data interchange attributes specified for the map) to identify the transformation map that applies to a transaction document in the FIND_TPMAP activity.
• When you register a pending outbound transaction document via the supplied APIs or using the supplied TXDOC_REGOUTBND or TXDOC_REGOUTX12 activities, LANSA Composer uses (and updates) the information on the Outbound Numbering tab to determine the control numbers used for the outbound document.  The TXDOC_ALLOCCTRL activity also uses this information (but it is not used in the supplied processes).

5. Copy and modify the supplied processing sequences as required

Although you may use the inbound and outbound processes as supplied, more commonly you will copy them and adapt to your own circumstances.  For example, as supplied, the inbound process makes simple assumptions about the type of transport to be used that may not be appropriate for your trading environment.