FOR_EACH_TXDOCO

LANSA Composer

FOR_EACH_TXDOCO

This is an iterator activity.  It will iterate for each pending outbound transaction document in LANSA Composer's document register that matches the criteria specified by the parameter values.  For each iteration, it provides the transaction document envelope number in the DOCNUMBER output parameter.

Typically a process using this activity specifies further processing directives nested beneath this iterator activity to extract or export, transform and send the pending outbound transaction document.

INPUT Parameters:

TRADINGPARTNER : Required

Specifies the trading partner whose pending outbound transaction documents are to be processed.

MAPID : Required

Specifies the transformation map identifier associated with pending outbound transaction documents to be processed.

PRODTEST : Optional

This parameter specifies whether production (P) or test (T) pending outbound transaction documents are to be processed.  If not specified, a default of production (P) is used.

DOCTYPE : Optional

This parameter specifies additional restriction on which pending outbound transaction documents are to be processed. If specified, only documents of a specific type will be processed.

DOCSTD : Optional

This parameter specifies additional restriction on which pending outbound transaction documents are to be processed. If specified, only documents of a specific standard will be processed.

DOCSTDVER : Optional

This parameter specifies additional restriction on which pending outbound transaction documents are to be processed. If specified, only documents registered as of a certain standard version will be processed.

DOCCONTENTTYPE : Optional

This parameter specifies additional restriction on which pending outbound transaction documents are to be processed. If specified, only documents registered as having a certain content type will be processed.

DOCDATAKEY01DOCDATAKEY02
DOCDATAKEY03

DOCDATAKEY04

DOCDATAKEY05

DOCDATAKEY06
: Optional

These parameters refer to application defined "keys" that may have been specified when douments were registered. If specified, only those documents registered with matching key will be processed.

OUTPUT Parameters:

DOCNUMBER 

Upon each iteration, this parameter will contain the transaction document envelope number of a pending outbound transaction document that matched the criteria specified.  This number is typically referenced in further processing directives nested beneath this iterator activity to extract or export, transform and send the pending outbound transaction document.

DOCTYPEOUT 

Upon each iteration, this parameter will contain the document type of a pending outbound transaction document that matched the criteria specified.

DOCSTDOUT 

Upon each iteration, this parameter will contain the document standard of a pending outbound transaction document that matched the criteria specified.

DOCSTDVEROUT 

Upon each iteration, this parameter will contain the document standard version of a pending outbound transaction document that matched the criteria specified.

DOCPRODTESTOUT 

Upon each iteration, this parameter will contain P for production usage or T for test usage.

DOCCONTENTTYPEOUT 

Upon each iteration, this parameter will contain the document content type of a pending outbound transaction document that matched the criteria specified.

DOCDATAKEY01OUT
DOCDATAKEY02OUT

DOCDATAKEY03OUT

DOCDATAKEY04OUT

DOCDATAKEY05OUT

DOCDATAKEY06OUT
 

Upon each iteration, these parameters will contain the application defined "keys" of a pending outbound transaction document that matched the criteria specified. If there are multiple sets of keys, only the first will be retrieved (see note below).

Note: It is possible for a single pending oubound transaction document to contain multiple individual messages, each of which may have their own set of staging database key values.  This typically happens, for example, for a complex outbound EDI transaction.  The output parameters containing the staging database keys will only contain the values for the FIRST message in this case.  This consideration does not apply to documents that are registered using the TXDOC_REGOUTBND, TXDOC_REGOUTEDI or TXDOC_REGOUTX12 activities, which permit only one message and therefore only one set of staging database keys to be registered.