Recommendations

The counterparty can send a FIX message with an unexpected message structure. It is possible if FIX Specification for the counterparty is unknown or the FIX dictionary is incorrect.

FIXEdge allows handling such cases if a user would explicitly check if tags are corresponding to the FIX message structure defined in the FIX dictionaries.

This approach allows keeping Business logic scripts unchanged while dictionaries are being modified or apply a single script for multiple message types with the different structure

If the user doesn't know if a tag is defined in the dictionary at the moment but there is a need to create a script using this tag the recommendations are the following:

1. Check if tag is defined for the message with functions isSupportedField(<fieldTag>), isSupportedField( <group handle> , <fieldTag> ) before accessing the fields.
2. In case of success perform the required operations.

Examples

1. Update Text(58) for all message types if it is applicable

The case is useful when the user wants to mark a message which is passing certain steps in the business logic the specific rule. 

The tag Text (58) doesn't present in all of the messages so the following Business logic will update it everywhere when it is applicable

• For all messages run the UpdateText.js script

  BL_Config.xml

          <Rule Description="Update Text for all messages from all sessions">
              <Source Name=".*" />
              <Action>
  				<!-- ... some business logic ... -->
  				<Script Language="JavaScript" FileName="../FIXEdge1/conf/UpdateText.js"/>
  				<!-- ... some business logic ... -->		
              </Action>
          </Rule>

• The script checks and updates the value of tag 58.

  UpdateText.js

  txt = "UpdateText.js was applied to the message";
  if (isSupportedField(58)) // If it is possible to update field 58
  	setStringField(58, txt); // update the text