Log2Orchestra is one of the tools related to the FIX Orchestra Technical Standard. It supports the automatic creation of an Orchestra XML file by using FIX engine logfiles as input. It is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s).

The tool parses the logfile(s) and retrieves not only standard FIX messages, fields and values but also any user-defined elements. For every FIX message type, it creates the superset of all fields found in any of the messages of that type. The input further requires a reference file that allows the tool to look up field names and other attributes for a given tag. The reference file can be any Orchestra XML file, including the official one from FIX representing FIX Latest for an Extension Pack. Your logfiles are not uploaded to FIX but processed on your local machine that has invoked the tool. You can specify the name of the resulting or output Orchestra XML file.

Enhancements provided with Version 1.3

Log2Orchestra no longer uses a default configuration for scenarios if no file is chosen. Previously, the default led to the creation of ExecutionReport(35=8) message scenarios for values of ExecType(150) and OrdStatus(39) found in the log file(s). Scenarios are now only created when a configuration file is uploaded by the user.

 Tag numbers found in the log file(s) are added to the Orchestra XML file even if they are not defined in the reference file. The main use case for this are user-defined fields in conjunction with FIX Latest as reference file. The field name is then generated as “Field” followed by the tag number , e.g. “Field20000”. The datatype of these fields is always set to “String”. Log2Orchestra Version 1.3 now sorts the field definitions by tag number as follows. The order of field references in message or component definitions is not changed.

• Standard fields (tag numbers 1-4999 and 40000 and above)
• Non-standard fields (tag numbers 5000-39999)

Bugfixes provided with Version 1.3

Log2Orchestra Version 1.2 did not display a correct error message when making changes to the log files in the background after having loaded them in the UI. Log2Orchestra support direct access to a public folder on GitHub that contains standard Orchestra XML files published by the FIX Trading Community. The file selection dialogue displayed all files and is now limited to files with the extension “.xml” for convenience.

The FIX Global Technical Committee (GTC) is proud to announce the update of Playlist to Version 1.2. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from Orchestra and use it to build the meta-data representation for one or more FIX interface(s). Log2Orchestra should be used if you wish to start with existing behavior of your implementation. Playlist should be used if you wish to start from standard FIX message definitions. The input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is recommended to use Orchestra Server, a service offered by FIX Trading for the maintenance for your Orchestra XML files. Access to the Orchestra Server is complimentary for members of the FIX Trading Community. Orchestra Server provides the necessary tools to manage FIX and non-FIX specifications based on the Orchestra Technical Standard. You can also create, browse, and export your Rules of Engagement specifications easily.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new output Orchestra XML file

What has changed with Playlist v1.2?

The latest version of Playlist now fully supports the display of union datatypes. Previously, they were only shown in the list of datatypes but never selected. Union datatypes are now shown wherever a field is displayed, including messages, groups and components. They are shown as selected in the list of datatypes as soon as at least one of the selected fields has a union datatype.

Repeating groups always start with a NumInGroup field to count the number of instances for tag=value encoding. This field is now displayed as part of the group and automatically selected as soon as at least one element of the group is selected. It is not necessary to manually select this field for a group. Additionally, the NumInGroup fields are displayed in the read-only list of fields.

More detailed information can be found in the Playlist User Guide.

Playlist v1.2 has fixed a few minor errors:

• In some cases, the removal of fields from messages also removed these fields from other messages if they had been selected there.
• In some cases, it was possible to deselect the last code of a code set (you need to remove the last field using the code set instead).

The FIX Global Technical Committee (GTC) is proud to announce the update of Playlist to Version 1.1. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the FIX Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s). Log2Orchestra should be used if you wish to start with existing behavior of your implementation. Playlist should be used if you wish to start from standard FIX message definitions. The input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is possible but not recommended to use an XML editor to maintain the Orchestra XML file directly. However, firms can create scripts or applications that read and manipulate the XML or markdown representation programmatically.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new output Orchestra XML file

What has changed with Playlist v1.1?

A major enhancement has been provided for minor extensions of an existing Orchestra XML file. A selector file can be used to preselect a subset of a larger input file, followed by the manual selection of additional elements and the creation of a new Orchestra XML file. This had been a known limitation in v1.0 that has now been removed.

Playlist was primarily designed to extract a subset of the FIX standard to develop a firm’s rules of engagement. You can select the relevant messages, and within a message select the fields to include, and select codes from a codeset that apply. However, in version 1.0, there was no way to add something back in if you simply forgot to check it before outputting a new Orchestra file. In the new version 1.1, you can reintroduce the original reference file and use your subset to pre-select all the items you selected on the first pass. Now you have the opportunity to select a forgotten field, and then rewrite the intended output.

Playlist is now able to directly access standard FIX Orchestra XML files from GitHub (e.g. FIX Latest) in the same way as supported by Log2Orchestra.

More detailed information can be found in the Playlist User Guide.

Playlist v1.1 has fixed a number of minor errors:

• It was possible to deselect an entire code set if it only has one code to begin with.
• It was possible to select entire sections if the first input file did not have it at all.
• A code set with duplicate values in the input file caused Playlist to hang.
• An empty category in the input file caused Playlist to hang.
• Invalid XML in the input file now triggers a popup with specific error information.

Log2Orchestra is one of the tools related to the FIX Orchestra Technical Standard. It supports the automatic creation of an Orchestra XML file by using FIX engine logfiles as input. It is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s).

The tool parses the logfile(s) and retrieves not only standard FIX messages, fields and values but also any user-defined elements. For every FIX message type, it creates the superset of all fields found in any of the messages of that type. The input further requires a reference file that allows the tool to look up field names and other attributes for a given tag. The reference file can be any Orchestra XML file, including the official one from FIX representing FIX Latest for an Extension Pack. Your logfiles are not uploaded to FIX but processed on your local machine that has invoked the tool. You can specify the name of the resulting or output Orchestra XML file.

Enhancements provided with Version 1.2

The Log2Orchestra UI now provides an additional window showing warnings generated during the processing of the input logfile(s). Each warning displays the line number of the logfile and references the tag numbers when applicable. The warnings can also be saved as a file to your local environment.

A number of optimizations were made regarding the content of the Orchestra XML file. The main change is that default values of attributes and internal elements and attributes are no longer created. This affects the following:

• Default value of attribute presence=”optional”
• Default value of attribute supported=”supported”
• Default value of attribute scenario=”base”
• Internal attribute latestEP=”…”
• Internal field attribute issue=”…”
• Elements <category> and <section>
• Attribute category=”…”

The various pedigree attributes (e.g. added, addedEP) are no longer copied from the reference file. The pedigree values in the FIX Latest reference file represent the history from a FIX point of view. Log2Orchestra is an aid to start the definition of an Orchestra XML file representing your FIX interface. The pedigree attributes may then be added to your initial Orchestra XML file to capture your versioning of this interface.

Bugfixes provided with Version 1.2

Log2Orchestra Version 1.1 transfers all datatypes from the reference file into the Orchestra XML file it creates. This resulted in redundant datatypes that are never used. Version 1.2 only transfers the datatypes required for the elements found in the logfiles.

Log2Orchestra Contributors

The FIX Global Technical Committee (GTC) invites FIX members to become contributors to the tools created for the membership. There is already a FIX Orchestra Working Group that maintains the FIX Orchestra Technical Standard and drives the business requirements for the related tools. The software for Log2Orchestra is not open-source and maintained in a private GitHub repository. If you are a FIX member participating in the FIX Orchestra Working Group and would like to actively contribute to the further development and testing of the software, you can request access to the GitHub repository and testing website. You will also be provided access to the Jira project used internally to track Log2Orchestra errors and enhancements.

The FIX Global Technical Committee (GTC) announces the availability of Playlist Version 1.0.1, fixing some errors detected in Version 1.0. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

Playlist is a tool to visualize an Orchestra XML reference file and reduce it to a subset exported into a new Orchestra XML file. Playlist is not a FIX validation tool, hence it relies on the correctness of the reference file and the FIX knowledge of the user. It is the responsibility of the user to ensure the proper selection of fields required by FIX, for example the tool will not complain if the user only selects stop order types but fails to select the StopPx(99) field. The only exception to this rule is that StandardHeader and StandardTrailer do not have to be selected and will automatically be added to each of the selected messages when creating the new Orchestra XML file. This includes the pre-selection of required fields in the StandardHeader component (BeginString(8), BodyLength(9), MsgType(35),…) for the tag=value encoding.

The following errors were fixed in Version 1.0.1:

• Standard header and trailer are automatically added to components, fields and code sets but not as component references to messages in XML file.
• All codes of a code set are deselected when deselecting a single code (only occurs when entire code set was previously selected implicitly by choosing a field in a message, group or component that uses this code set).
• Preselected fields of standard header and trailer are automatically selected again when deselecting one or more of their fields before selecting the first message.
• Playlist hangs when using a reference file without messages.
• Reference file is deemed invalid when creating Orchestra file from preselection, i.e. not making any manual selections.
• Reference file is deemed invalid when message attribute category is not used.

The following enhancements were made in Version 1.0.1:

• Display of group name for code set values when applicable.

• Provide direct link to the Playlist User Guide.

The FIX Global Technical Committee (GTC) is proud to announce the availability of Playlist Version 1.0. If you are a FIX member, you can request access from the FIX Program Office. It can then be invoked either via its own URL or through the FIX website (“Playlist” in the dropdown menu “Tools” or from the Orchestra landing page). You have to be a FIX member and logged into the FIX website with your user account linked to your firm.

What is Playlist?

Playlist is the second tool related to the FIX Orchestra Technical Standard. Playlist is a web-based tool available through the FIX website that allows the user to generate a base Orchestra XML file by selecting what they need from an input Orchestra reference file.

Similar to Log2Orchestra, it is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s). The reference input file used by Playlist can be an officially published version of FIX Latest or also your own Orchestra file. You do not require any log files from an existing FIX interface to be able to use Playlist. Once an Orchestra XML file has been created with Playlist, you can use Tablature to convert it to and from markdown for maintenance and extensions. It is possible but not recommended to use an XML editor to maintain the Orchestra XML file directly. However, firms can create scripts or applications that read and manipulate the XML or markdown representation programmatically.

The following basic steps are required to create an Orchestra XML file with Playlist.

1. Choose an Orchestra XML file as your input reference file that will be loaded only into your local browser
2. Select the messages, groups, components as well as their fields and values that you want to support
3. Choose a name for the new Orchestra XML file to output to and select “Create Orchestra file”
4. Select “Download File” and choose a directory to store the new Orchestra XML file

More detailed information can be found in the Playlist User Guide.

The FIX Global Technical Committee (GTC) announces the availability of a new version of the Log2Orchestra utility. Log2Orchestra is the first in a series of tools related to the FIX Orchestra Technical Standard. It supports the automatic creation of an Orchestra XML file by using FIX engine logfiles as input. It is intended to be the starting point for someone who wants to benefit from FIX Orchestra and use it to build the meta-data representation for one or more FIX interface(s).

The tool parses the logfile(s) and retrieves not only standard FIX messages, fields and values but also any user-defined elements. For every FIX message type, it creates the superset of all fields found in any of the messages of that type. The input further requires a reference file that allows the tool to look up field names and other attributes for a given tag. The reference file can be any Orchestra XML file, including the official one from FIX representing FIX Latest for an Extension Pack. Your logfiles are not uploaded to FIX but processed on your local machine that has invoked the tool. You can define the name of the resulting Orchestra XML file.

Enhancements provided with Version 1.1

Log2Orchestra now provides direct access to official FIX Orchestra reference files in the public GitHub project FIX Orchestrations. You may still use local reference files (click on “Choose File”) but do not have to download any of the official files for FIX 4.2, FIX 4.4 or FIX Latest from the FIX website. Simply click on “FIX Standard” to get a list of XML files available in the FIX Standard folder in GitHub:

Log2Orchestra counts the number distinct elements included in the logfile(s). Version 1.0 had been showing a number for component scenarios although only message scenarios are currently supported by the configuration file. This number has been replaced with the number of code sets, i.e. sets of enumerated values used for one or more fields.

Bugfixes provided with Version 1.1

Log2Orchestra had problems with larger logfiles that were not processed correctly, leading to incorrect counts of elements. User-defined fields were created even if they were not present in the logfile(s). These issues have been resolved.

Log2Orchestra creates a meta-data element with a number of attributes conforming to the Dublin Core Metadata Initiative. Version 1.0 copied the attribute values from the reference file. This has been corrected to the perspective of the user of Log2Orchestra.

Additionally, a few minor corrections to the handling of the user interface have been made.

Log2Orchestra Contributors

The FIX Global Technical Committee (GTC) also invites FIX members to become contributors to the tools created for the membership. There is already a FIX Orchestra Working Group that maintains the FIX Orchestra Technical Standard and drives the business requirements for the related tools. The software for Log2Orchestra is not open-source and maintained in a private GitHub repository. If you are a FIX member, part of the FIX Orchestra Working Group and would like to contribute to the further development and testing of the software, you can be given access to the GitHub repository and testing website. You then also have access to the Jira project used internally to track software errors and enhancements for Log2Orchestra.

Please send an email to fix@fixtrading.org if you would like to access the Log2Orchestra tool, participate in the FIX Orchestra Working Group and/or offer your help as a tool contributor.

FIXimate stands for FIX Interactive Message and Tag Explorer and is the visualization tool for the FIX Repository, which contains the meta-data for the FIX application and session layer.

Introduction

FIXimate makes the FIX Repository easily accessible and serves as a quick reference to lookup information about FIX messages, components, fields and values. FIXimate has been available for many years now and is being widely used, primarily by those that are already familiar with FIX. FIXimate is a navigable guide to the content in the FIX Repository supported by FIX Latest, which includes definitions for messages, components and fields. FIX Latest now has more than 160 messages and around 6,000 fields, making the availability of a tool an absolute necessity to find the subset of elements for a given set of requirements for a FIX interface.

A comprehensive user guide is available online via FIXimate. This blog explains the main concept and some of the new features available in FIXimate4.

Screen Layout

The first area on the upper left-hand side of the screen provides information about the tool itself.

FIXimate includes several search functions to lookup a specific message by its type, or a specific field by its tag number or name. It also supports search using free text or regular expressions to produce a list of messages, components, fields, code sets, and codes (a.k.a. enum values) containing this text in their name and/or description.

FIXimate then offers menu options with different sort orders for various elements, e.g. for fields and messages. The user can click on a menu option to display more detailed information.

The last area on the left-hand side menu provides direct access to individual FIX messages. The menu list is structured by business area (e.g. Pre-Trade) and category (e.g. Market Data), with FIX messages expanded for the selected message category. Multiple categories can be expanded at the same time.

What’s new?

FIXimate4 is the next generation of FIXimate and is fully based on the Orchestra XML format of the FIX Repository that follows the FIX Orchestra Technical Standard (FIXimate3 uses the FIX Unified Repository format). The following sections highlight the major changes and enhancements that are provided with FIXimate4.

Permanent URLs

URLs to elements of the FIX Repository are now permanent and directly accessible, i.e. they no longer include the Extension Pack number, and use the unique and persistent identifier from within the FIX Repository. For example, the URL to NewOrderSingle(35=D) changes

FROM: https://fiximate.fixtrading.org/en/FIX.Latest_EP266/body_495268.html

TO: https://fiximate.fixtrading.org/en/FIX.Latest/msg14.html

The new URL is a result of the NewOrderSingle(35=D) being defined in FIX Orchestra as:

<fixr:message name=”NewOrderSingle” id=”14″ msgType=”D” … />

where

              id=”14″

refers to the immutable message ID for NewOrderSingle.

Pedigree information

Pedigree covers the history of FIX Repository elements being added, modified or deprecated. This was mainly limited to the pedigree of fields in the lower pane and has now been enhanced to also provide pedigree for the usage of fields and components within messages and components. This information is shown when displaying messages or components in the upper pane. Pedigree information has always been in the FIX Repository but had not been visualized in FIXimate3. The following screenshot shows the first few fields of the NewOrderSingle(35=D) message.

Code sets

Code sets, previously known as “enumeration values”, were introduced with the FIX Orchestra Technical Standard and represent a list of codes for a FIX field. The FIX Unified Repository attached enumeration values to a specific fields and other fields could re-use those values by referencing it. FIXimate3 visualized this relationship with the column “Enums from tag” on the far right of the lower pane.

FIX Orchestra defines “code sets” as independent of a specific field and all fields wanting to use a given code set simply reference the same code set. Code sets have a base datatype, e.g. “int”, that is identical for all codes in this set. FIXimate4 displays the base datatype as well as the code set, e.g. OrdType(40) has datatype char and uses the code set OrdTypeCodeSet.

The code set itself can be displayed by clicking on its name:

Search fields and components by dropdown list

FIXimate3 supported the search of fields by entering the name in a search box, however, the full name had to be provided for the search to be successful. It was easier to use the regular expression search box right beneath it since that allows only part of a name to be entered, resulting in not only fields but also messages, components and descriptions containing that search string.

FIXimate4 now offers dropdown lists with a type-ahead function and not only for fields but also for components and code sets.

Search abbreviated names

FIXimate4 supports the search of abbreviated names that exist for messages, components, and fields. These are primarily relevant for the FIXML encoding of messages. There is an additional checkbox below the generic search box called “Match abbreviated name only“. When this checkbox is selected, the results will display only those messages, components, and fields where their abbreviated name contains the search pattern.

Use Cases

How should you manage multiple rules of engagement using Orchestra?

Q. For instance, how do you use Orchestra to represent multiple order routing destinations? An order routing hub is responsible for translating incoming messages into the FIX format accepted by each destination broker or market.

A. To simplifiy the problem, each Orchestra file should only represent one service offering. In other words, one set of message structures and workflows exposed to clients of a system. Therefore, there should be one Orchestra file representing the hub to its direct clients, and one Orchestra file for each of the order destinations. The logic of the routing hub can use the set of Orchestra files to inform decision making about which routes have a particular capability, e.g. which ones accept a certain order type or message type.

Orchestra Syntax

How do you encode that a field is conditionally required depending on the value of another field?

Q. Say, for example, that a SecurityIDSource (tag 22) associated with SecurityID (48) can be SEDOL (code 2), ISIN (4), or RIC (5). In the rules of enagement, Currency (15) is usually an optional field, except when SecurityIDSource is ISIN, Currency is required. How can this rule be encoded in Orchestra?

A. Insert the following snippet into a message to encode the rule. The <when> element contains a Score DSL expression that tells when the rule is effective. It says that the Currency field (tag 15) is required when the value of the SecurityIDSource field in the same message is equal to the value of the code named ISIN. (See the Orchestra specification for the Score expression syntax.)

<fixr:fieldRef id="15">
    <fixr:rule name="currencyRule" presence="required">
        <fixr:when>SecurityIDSource==^ISIN</fixr:when>
    </fixr:rule>
</fixr:fieldRef>

To Submit a Question

Post an issue to GitHub

Questions about the Orchestra Standard

Questions about Technical Resources

© Copyright 2019 FIX Protocol Ltd.

How to Access an Orchestra File

An Orchestra file contains message definitions and workflows. When you receive an Orchestra file from a trading counterparty, how do you access it programmatically to discover its elements?

An Orchestra file is encoded in XML and must conform to the schema published in GitHub project FIXTradingCommunity/fix-orchestra. There are actually two XML schemas in Orchestra, in modules repository2016 and interfaces2016. The first is for message definitions and workflows, and the latter is for defining service offerings, protocol stacks, and sessions. For this tutorial, we’ll work with the repository schema, but interfaces access works the same way technologically.

Prequisites

For this tutorial, we’ll work in the Java programming language, using Maven as the build tool. So you’ll need Java 8 or later and Maven 3 for the steps below. (Of course, XML can be read and manpulated in other programming languages using appropriate tools.)

Step 1: Create a new project

Create a new simple Maven project. IDEs such as Eclipse or Intellij IDEA have menus and dialogs for this.

Code to access or update an Orchestra file is available as open source. To make it easy on yourself, let Maven retrieve a pre-built excutable for you. If you’d rather dive into detail, you can build the dependency yourself from source–see below.

Use pre-built XML bindings

XML bindings relieve you of having to deal with XML details such as elements and attributes. Rather, you just use plain old classes and objects (POJOs).

Orchestra XML bindings generated with Java Architecture for XML Binding (JAXB) are already baked into an open-source project for you to use. Add this snippet to the <dependencies> element of your Maven project file. (Check if there is a later version available in Maven Central repository.) When you build your project, Maven will retrieve each dependency in your project automatically.

<dependency>
  <groupId>io.fixprotocol.orchestra</groupId>
  <artifactId>repository2016</artifactId>
  <version>1.3.0-RC4</version>
</dependency>

Note: if you’re using Java 9 or later, you’ll have to add dependency for module javax.xml.bind since JAXB has been moved out of the base module.

Alternative: Generate XML bindings from source

If you wish to build the XML bindings from scratch, retrieve the source for the module described above from GitHub module repository2016. Tell your IDE to build the project, or issue this command line from the root directory of the dependency project:

mvn install

In the generate-sources phase of the build, JAXB source code is generated to access or update elements of an XML file that conforms to the Orchestra schema. Then the source code is compiled, packed into a .jar file, and stored in you local Maven repository, making it available to your new project.

Step 2: Create a class to report Orchestra messages

Let’s create a class to report the messages contained in an Orchestra file. For this to work, the class has to parse the XML file and convert XML constructs into Java objects. The class will have a method to accept an input stream for the file, and an output stream to send text to. Start with this outline:

package com.example.orchestra.sample;

import java.io.InputStream;
import java.io.PrintStream;
import javax.xml.bind.JAXBContext;
import javax.xml.bind.JAXBException;
import javax.xml.bind.Unmarshaller;
import io.fixprotocol._2016.fixrepository.Repository;

public class RepositoryReporter {

  public void report(InputStream is, PrintStream os) {
    try {
      // parse the XML
      Repository repository = unmarshal(is);
      // report messages
      // TODO
    } catch (JAXBException e) {
      // print exception
      os.format("ERROR: %s%n", e.getMessage());
    }
  }

  private Repository unmarshal(InputStream is) throws JAXBException {
    final JAXBContext jaxbContext = JAXBContext.newInstance(Repository.class);
    final Unmarshaller jaxbUnmarshaller = jaxbContext.createUnmarshaller();
    return (Repository) jaxbUnmarshaller.unmarshal(is);
  }

}

To report all the messages in the Orchestra file, insert this snippet into the report() method. It accesses a list of all messages in the repository and invokes a new method to report each message.

      List<MessageType> messageList = repository.getMessages().getMessage();
      reportMessages(messageList, os);

The new method is:

  void reportMessages(List<MessageType> messageList, PrintStream os) {
    // iterate all messages in the file
    for (MessageType message: messageList) {
      os.format("Message name: %s scenario: %s MsgType: %s%n",
          message.getName(), message.getScenario(), message.getMsgType());
      // report message members
      // TODO
    }  
  }

To list the members of a message structure, insert this snippet into the reportMessages() method. The structure of a message is mixed collection of field, component, and repeating group references.

      List<Object> members = message.getStructure().getComponentRefOrGroupRefOrFieldRef();
      reportMembers(members, os);

Add a new method to report each of the members. It has to check the type of each object in the mixed collection. To keep it simple, we’ll only report the identifiers of each member, but you can expand the code to report more attributes.

  void reportMembers(List<Object> members, PrintStream os) {
    for (Object member : members) {
      if (member instanceof FieldRefType) {
        FieldRefType fieldRef = (FieldRefType)member;
        os.format("tFieldRef id: %d scenario: %s%n", fieldRef.getId(), fieldRef.getScenario());
      } else if (member instanceof ComponentRefType) {
        ComponentRefType componentRef = (ComponentRefType)member;
        os.format("tComponentRef id: %d scenario: %s%n", componentRef.getId(), componentRef.getScenario());
      } else if (member instanceof GroupRefType) {
        GroupRefType groupRef = (GroupRefType)member;
        os.format("tGroupRef id: %d scenario: %s%n", groupRef.getId(), groupRef.getScenario());
      }
    }
  }

Your homework

Accessing fields, components, and repeating groups follows the same format, so you can write their accessors by following the style for messages.

This simple tutorial reports on each element as it is accessed. However, a real application would likely need to collect information and cross-reference elements before processing them. For example, a FieldRef member of a message is only identified by its numeric ID (field tag). To get the field name, you have to cross-refernce the Field element with the same ID.

Caution: not all XML attributes are required, so some accessors may return null. Be careful to check for nullness before attempting to use a returned object reference.

Step 3: Create a main and build the application

Create main() entry point to receive command-line arguments like so:

public class RepositoryApp {
  public static void main(String[] args) {
    if (args.length < 1) {
      usage();
    } else {
      RepositoryReporter reporter = new RepositoryReporter();
      InputStream is;
      try {
        // first argument is an Orchestra file name
        is = new FileInputStream(args[0]);
        reporter.report(is, System.out);
      } catch (FileNotFoundException e) {
        System.err.println(e.getMessage());
      }
    }
  }

  public static void usage() {
    System.err.println("Usage: RepositoryApp <xml-file>");
  }
}

Tell your IDE to build the project, or issue this command line from the root directory of the project:

mvn install

Now your first Orchestra application is ready to run! Output should look something like this:

Message name: NewOrderSingle scenario: SecurityType-Future MsgType: D
    ComponentRef id: 1024 scenario: base
    FieldRef id: 11 scenario: base
    FieldRef id: 1 scenario: base
    FieldRef id: 21 scenario: SecurityType-Future
    ComponentRef id: 1003 scenario: SecurityType-Future
    FieldRef id: 54 scenario: SecurityType-Future
    FieldRef id: 60 scenario: base
    ComponentRef id: 1011 scenario: SecurityType-Future
    FieldRef id: 40 scenario: SecurityType-Future
    FieldRef id: 44 scenario: base
    FieldRef id: 59 scenario: SecurityType-Future
    ComponentRef id: 1025 scenario: base

Copyright 2019 FIX Protocol Ltd.