Outbound transmission creation

The build transmission request can be generated in the following ways:

The user initiates a build transmission request from within the Distribution user interface.
The cutoff time for the transmission is passed.
The transmission meets one of the transmission thresholds (maximum number of transactions, the maximum value, or the maximum size in bytes).
For more information about the application of threshold parameters that control the structure of transmissions, see Transmission Definition and Global Details.

When an outbound segment is created, it must be within the structure of an outbound batch (ICL). Segments are grouped within batches (ICLs) by their endpoint, business day, and bank. An outbound batch (ICL) contains only segments (or transactions if non-check formats) for the same endpoint, business day, and bank.

Segments are only used for check format type transmissions. For other types, transactions are mapped directly to outbound batches.

The outbound transmission contains outbound batches (ICLs) that are assigned to the same participant and transmission definition. Each outbound batch (ICL) is associated with an endpoint, and each endpoint is associated with a transmission definition. Because multiple endpoints can refer to the same transmission definition, an outbound transmission can contain outbound batches (ICLs) destined for multiple endpoints. Each row in the outbound transmission table represents an instance of a transmission to be sent to a participant.

Outbound transmissions have a cutoff time, which is when new transactions are no longer added to the transmission. They also have a deadline, which is the time by which the transmission must be sent. The cutoff and deadline are defined at the participant level for a particular transmission definition. When a batch (ICL) is assigned to a transmission, the engine looks for an open transmission with the specified business day, participant, and transmission definition. If it does not find an open transmission, it uses the next closest cutoff date that is not passed to create an outbound transmission for that cutoff and deadline.

Creating X9 transmissions

For X9 transmissions, when the cutoff time passes, the engine automatically builds the transmission. Any open segments that are associated with the transmission are built, and the batch (ICL) header, file header, and control records are written to the transmission.

The batch (ICL) header, file header, and control records are built by using the bank, participant, and transmission definitions that are defined. The bank and participant definitions have the institution names and routing numbers for the originating and receiver institutions, along with contact names and phone numbers. File and batch (ICL) header records have fields for the date and time the transmission and batch (ICL) were created. The time zone that is specified in the transmission definition determines the time zone that is used for the date and time. Under normal clearing arrangements, specify these values by using the GMT time zone.

The File creation root property in the Distribution transmission properties controls the root directory where the files are written. The directory structure under the file creation root consists of the business date, business category, and participant ID.

Creating NACHA transmissions

For NACHA transmissions, the transmission file is created and a file header record is written when the mapping of the first outbound batch is finished. Batches and their header and control records are then appended to the file one-by-one as the mapping for each of those batches is finished. This NACHA transmission file build process is provided by the batch build scheduler task.

The Batch build task poll interval, the Maximum batch count, and the Maximum item count Distribution properties are used to control how this task runs. If the Batch build task poll interval is set to a value of 0, the task does not run. Also, if a NACHA electronic format is not defined, the task does not run. If the Batch build task poll interval is later set to a positive value, or a NACHA electronic format is added, and you want to run the batch build scheduler task, the Distribution engine must be restarted.

When the cutoff time passes, any open batches that are associated with the transmission are appended to the file, the file control record is written, and the file is closed.

Creating FTM Workflow transmissions

FTM Workflow transmissions are created when the Distribution mapper process puts FTM base-batch-build-request messages on the Distribution batch IBM® MQ queue. Each of these messages causes a batch listener (IZL Batch Listener) thread to run. This thread creates the outbound FTM database artifacts that are related to the transmission elements (outbound batch and associated payments) that are specified in each message. This process is called the FTM base-batch-build process.

Each FTM base-batch-build-request message contains one or more outbound batch IDs and a list of transactions for each of those batches. The batch IDs that are contained in a message depends on when it is issued. The point in the Distribution mapper process when the messages are issued depends on the value in the Payment Mapping Count property. This property is the number of payments from the incoming batch to put in a single group. The values for the property are shown in the following list.

The Payment Mapping Count property is set to zero.: The FTM base-batch-build-request messages are issued when the mapper process sets the status of an outbound batch to closed. This status occurs when the number of payments that are assigned to that batch cause any one of the configured threshold limits to be met, or when a batch-to-batch mapping process completes. The FTM base-batch-build-request messages contain the outbound batch ID and associated transactions of the batch that was closed.; When Distribution completes the mapping process for an inbound batch, messages are issued for each related outbound batch that is still in an open status. Open batches are the batches for which a threshold limit was not met, or they are not batch-to-batch enabled batches. The FTM base-batch-build-request messages contain the outbound batch IDs and associated transactions of the related outbound batches that are still in open status.
The Payment Mapping Count property is greater than zero.: The FTM base-batch-build-request messages are issued when each mapper thread finishes mapping its payment group. The FTM base-batch-build-request messages contain the outbound batch ID and associated transactions of the payment group that finished mapping.

Several properties control the FTM base-batch-build process. They can affect the performance of this process and the resources that it uses. Issuing multiple FTM base-batch-build-request messages effectively builds the related database artifacts in parallel to each other and in parallel with the mapper process. The following properties are used to configure the content and number of batches and transactions that are associated with each FTM base-batch-build-request message.

Maximum batch count: When it is time to issue a message, the number of batches and transactions that the request is to be issued for is examined. If the number of batches exceeds the value in this property, multiple request messages are issued such that each message does not have a batch count greater than this maximum batch count.
Maximum item count: When it is time to issue a message, the number of batches and transactions that the request is to be issued for is examined. If the number of transactions exceeds the value in this property, multiple request messages are issued such that each message does not have a transaction count greater than this maximum transaction count.

To build more database artifacts in parallel, do the following property changes.

Increase the number of batch listener (IZL Batch Listener) threads.
Enable the Payment Mapping Count by setting it to a nonzero value.
Decrease the number in the Maximum batch count and Maximum item count properties.

These properties also affect the Distribution batch queue utilization. For example, the size of the FTM base-batch-build-request messages.

When a batch listener thread runs as a result of processing an FTM base-batch-build-request message, it does the following functions.

Updates the database. If the necessary database records exist, their values are updated to reflect the changes to the FTM transmission. For example, the number of batches. If no database records exist, the following database artifacts are created.
- A row is inserted for the FTM transmission if it does not exist.
- A row is inserted for every FTM batch if they do not yet exist.
- A row is inserted for each FTM transaction in the transmission.
Populates the objects by using the bank, participant, and transmission definitions that are defined. The bank and participant definitions have the institution names and bank identification codes for the originating and receiver institutions, along with contact names and phone numbers.

When a build and release request is issued for an outbound transmission, it causes a Distribution file listener (IZL File Listener) thread to run. When that thread runs, it first checks whether the FTM base-batch-build process created all the related FTM database artifacts. If the process created the database artifacts, the transmission is put into released status. Then, a transmission-released message is sent to the queue that is configured in the FTM Workflow Channel that is associated with the outbound transmission.

The IBM App Connect application that receives the transmission-released message processes the data in the FTM database tables and posts appropriate messages to the Distribution file queue. These messages indicate that the IBM App Connect application is transmitting, finished transmitting, or encountered an error. As each message is received, Distribution updates the transmission status to reflect the status that was sent in the message.

If all FTM base-batch-build-request messages are not yet processed, the outbound transmission remains in queued status until all the FTM base-batch-build-request messages are processed and the FTM base-batch-build process finishes. When it completes, the transmission is put in released status and a transmission-released message is posted.

Releasing transmissions

When a transmission is built because one of the transmission thresholds is met, several configuration parameters determine when the transmission is released. The transmission is automatically released when one or both of the following conditions are true:

The No Earlier Than attribute that is associated with the transmission delivery time is set to no.
The No Earlier Than attribute is set to default and the Auto release property is set to true.

The transmission is not copied to the release location folder when any of the following conditions is true:

The No Earlier Than attribute is set to yes.
The No Earlier Than attribute is set to default and the Auto release property is set to false.

Notes:

The No Earlier Than attribute is configured on the receiver transmission deliveries details page. For more information, see Manage Transmission deliveries page.
The Auto release property is configured on the Distribution transmission properties page. For more information, see Transmission properties page.
The holidays that are specific to a participant are ignored when a cutoff and deadline are assigned to an outbound transmission.

When the cutoff for a transmission occurs, an IBM MQ message is placed on a queue that the broker workflow is monitoring. When the message is received, the broker workflow uses the workflow definition to begin mapping and routing the transmission.

However, when the cutoff for one of the following transmissions occurs, the transmission is written to the folder specified in the Release location transmission property instead.

A NACHA transmission
An X9 transmission