There were many transactions for different trading partners that were successfully "Added to batch for scheduled transmission successfully" back on Feb 2, 2018, however due to an system issue, these transactions were never sent successfully to the trading partner, because no response was received by the waiting BW process and therefore BatchingTransactionTrigger was never issued.

Exactly one year later on Feb 2, 2019, all of the failed outbound transactions were collected "Collated for batch transmission successfully" and sent to trading partner "Transaction(s) sent to Trading Partner in batch successfully" . There was no external service that will have triggered this scenario. 

 

When using the Service protocol within the EDI Protocol plugin, a batch transaction was sent one year after the transactions were placed into BC.

AIX 6.1

Using the TransactionTrigger Service, a BW process sends BC a number of transactions using a common transaction grouping ID.  Under normal conditions, the BW process listens to BC INITIATOR.RESPONSE queue for these messages via BW ReceiveResponse and crosschecks the received responses against the ones sent into BC.  Once all the expected number of status code=200 responses for the transactionGroupingID/transactionIDs were received, a BatchingTransactionTrigger was issued via a BW SendRequest task to BC to trigger the transmissionID and sent the batched transactions to the Trading Partner.

The txnGroupingID parameter of SendRequestInput was used to batch the transactions based on group-id. Transactions batched based on this parameter are not processed immediately by the scheduled task poller as per the settings in the BusinessAgreement (the scheduled transmission time is set to one year in the future).   Because of a system crash, the TransactionTrigger never occurred, although the transactions stayed queued for one year in the future.

The SCHEDULED_TASK_POLLER table polls the BC_SCHEDULED_TASK table at regular intervals (default is 60 seconds and configurable by setting the property bc.task.scheduler.pollingInterval) where it searches for the task entries. In case of batch transactions it selects the task which satisfies any of the two conditions below.

1. NEXTSTARTTIME < current_system_time
2.Transactions which are batched >= Max number of transactions to be batched.

In this case the first condition was met, so the transaction was triggered in 2019. 

The batch can also be triggered from the Message Queue using the GUI.


 

txnGroupingID, batch, SCHEDULED_TASK, NEXTSTARTTIME