Planning your Implementation

Amongst the tasks you need to perform when planning your implementation is to gather information about the following:

1. Identify document types and standards applying to your implementation

• Identify the document types (for example, EDI, XML, CSV) that your implementation will use and how they will be represented in LANSA Composer.

• Identify the particular standards and/or versions that apply to those document types and how they will be represented in LANSA Composer.

• Locate and acquire the references that your implementation will use to effect mapping (and validation, if applicable) of the transaction document types and standards you have implemented.  For XML documents, for example, you will need access to the relevant document DTD or schema.  For text or CSV documents, you will need access to a reference that completely describes the document format.  For EDI documents, you will need access to the SEF/LSEF file that describes the standard and you will need to connect that to the applicable LANSA Composer document standard for use by EDI-specific parts of the framework such as the DISCOVER_EDI activity.

2. Identify your trading partners and trading agreements

• Identify the trading partners with whom you will exchange transaction documents.

• Understand any trading agreements that may govern the transaction document exchange with those trading partners.

• If applicable, categorize your trading partners and agreements such that you can identify the processes that will be common. Assuming that you interact with at least some groups of your trading partners in the same ways, your objective should be to build common processes (or adapt the supplied processes) such that they can serve more than one trading partner relationship.  LANSA Composer contains specific features to support this.

• Gather information for each trading partner that will enable you to implement the agreed document exchange.  Of course this includes the agreed document types and standards, but also you need to gather the specific details that will enable you to implement the agreed transport protocols, such as FTP address and credentials.

3. Understand your application(s) with which the solution will integrate

• Identify your existing application(s) that will be involved in the transaction document processing.

• Understand the relevant parts of the application's database and any rules that govern it.

• Determine the division of responsibilities between the application and your transaction document processing solution. For example, define the extent to which each of them is responsible for cleaning and validating any in-coming transaction data in order to meet the application's processing requirements.

• Identify integration touch-points. Clearly this must include shared database access, but also any program-level integration. For example, the inbound process may need to call an application program or start an application process on receipt of an in-coming transaction.  Or your application may need to start the outbound process in response to application events that indicate that an outbound transaction document is to be sent.

4. Determine the most appropriate approach to mapping transaction data

• Decide whether the transformation maps that you will create for your transaction document processing requirements should directly address existing application database tables or instead should use an intermediate "staging" database:

• Having your transformation maps directly address the application database tables is usually the quickest and simplest solution to implement.  However, this may not be appropriate if this results in the solution  bypassing data cleansing and integrity provisions of your existing applications.

• Using an intermediate "staging" database helps to insulate your application from the interfaces that the transaction document processing solution opens to the outside world and affords you the opportunity to implement comprehensive data cleansing and integrity measures.  However, this approach is somewhat more complex and costly to implement and may require you to perform additional coding to provide import and/or export processors that support this approach (though it will often be possible to re-use or adapt existing programs for this purpose).

Integration with operational procedures, if necessary

• Adapt your operational procedures to accommodate your transaction document processes.  Depending on your trading partner agreements, there are a number of ways in which transaction document exchange with your trading partners may be initiated.  Some possibilities are that you may need to add periodic processes to your operational task scheduler or batch processing streams to poll for available inbound transaction documents.

• Allocate responsibility for monitoring and acting upon exceptions that occur in your transaction document flows.  You may wish to take advantage of LANSA Composer's in-built event notification features to have selected groups of users automatically notified of exceptions that occur.