...

• Do not accept a session with unexpected sequences (Default behavior).
  The FIXEdge user can detect this issue and should communicate with the sender in order to resolve the situation manually.
  In FIXEdge.properties:
  IgnoreSeqNumTooLowAtLogon = false
• Accept session with a low sequence. The missing messages will be not requested.
  The process of recovery becomes automated, no manual session recovery is needed by the cost of missing messages.
  If a party lowers or reset Sequence Number, it means that all previous messages are considered as non-important and can be lost.
  In FIXEdge.properties:
  IgnoreSeqNumTooLowAtLogon = true

Users should apply the best strategy for their case.

...

Error events types for the configuration above:

• Business Logic OnUndeliveredMessageEvent event is called when the destination is not available.
• Business Logic OnRuleFailEvent is called when js execution fails or configuration is wrong.

...

In the case of FIXEdge failures or, network failures, or if the connection is dropped all non-delivered messages will remain as undelivered in the storage.  Once the connection will be recovered, FIXEdge tries to finish the delivery and resend messages to IBM MQ Server.

In case if the IBM MQ server (WebSphere) is not available (e.g. stopped) there will be the next error in the logs.

ERROR [MQQueueWrite] <thread> MQ PUT Commit on queue '<src queue>' failed

...

Additional information about persisting state of transactions can be found: Transactions in MQ

Error queue management

The messages for the error queue can be re-processed using dmpmqmsg tool. The tool can move messages across queues and should run on the server with IBM WebSphere. 

...

All such cases should be considered independently 

The messages that came from transport adaptors must be routed somewhere. If the destination specified in the BL rule is not found then FIXEdge will raise a "Sending message to TL failed" error. 

The user can use the Condition element for filtering messages to specifying the destinations. If there are no suitable conditions in the BL rule the message will not be delivered anywhere and the will be the next error.

2021-07-07 17:45:49,565 UTC   DEBUG   [BL_RoutingTable]  24288  No BL rules found for message with ClientID 'MQHub2', executing DefaultRule.
2021-07-07 17:45:49,565 UTC   DEBUG   [CC_Layer]  24288  BL has processed a message. Number of client IDs for delivery :0. Number or FIX sessions for delivery :0.. Number or sources identifiers for delivery :0.
2021-07-07 17:45:49,565 UTC   ERROR   [MQQueuesReader]  24288  Sending message to TL failed. Reason: TL has returned false.
2021-07-07 17:45:49,565 UTC   DEBUG   [MQQueuesReader_Debug]  24288  Sending to Error queue.

For Example 

If the following BL rule results with the above error, that means that the incoming message does have ".*MATCHTHISTEXT.* in the tag 55

<?xml version="1.0" encoding="UTF-8"?>
<FIXEdge>
    <BusinessLayer>
        <!-- Routing Rule for MQHub incoming messages -->
        <Rule>
            <Source Name="MQHub2" />
            <Condition>
                <MatchField Field="55" Value=".*MATCHTHISTEXT.*"/>
            </Condition>
            <Action>
                <Send Name="FIXCLIENT" />
            </Action>
        </Rule>
        <DefaultRule>
            <Action>
                <DoNothing/>
            </Action>
        </DefaultRule>
    </BusinessLayer>
</FIXEdge>

To troubleshoot the user should check message content if message content fits if is not fitting apply additional conditions covering adding in the rules for another condition

When there it will be a destination for the message, the user will have the next output specifying that the message has a delivery point.

2021-07-22 20:56:45,325 UTC   DEBUG   [BL_RoutingTable]  8848  Found 1 suitable rules for message with ClientID 'MQHub2'
2021-07-22 20:56:45,325 UTC   DEBUG   [CC_Layer]  8848  BL has processed a message. Number of client IDs for delivery :0. Number or FIX sessions for delivery :0.. Number or sources identifiers for delivery :1.
 
    Source IDs:
        1. 'FIXCLIENT'
 
2021-07-22 20:56:45,325 UTC   DEBUG   [FL_MsgTrace]  8848  Sending FIX message to session with ID 'FIXCLIENT'. Message: '8=FIX.4.49=15835=D49=FIXCLIENT56=FIXEDGE34=252=99990909-17:17:1711=Order#064=2021021921=3100=155=MATCHTHISTEXT54=160=20210219-04:11:46.76838=2000040=244=34.710=065'.
2021-07-22 20:56:45,437 UTC   DEBUG   [MQQueueRead]  8848  MQ GET Commit took 111.15ms, res: 1
2021-07-22 20:56:45,437 UTC   DEBUG   [MQQueuesReader_Debug]  8848  1 messages are removed form client Queue.

8. The network between FIX Client (Recipient) and FIXEdge is down or the session is offline

...

If configuring proper schedule is not flexible enough and it is required to deliver missing messages the next day after sequence reset, it is recommended using the Managed Queue feature implementing a store-and-forward workflow.

...

It happens when FIXEdge tries to send a message from MQ but the session is offline and property for rejection fix messages in case of disconnection is set:

• Business Logic OnUndeliveredMessageEvent event is called in these cases

It is not recommended to use logic for sending messages in the same session again if the first attempt has failed and the OnUndeliveredMessageEvent event is called.

MQ TA Configuration

...