Generating FIXML Messages Using InfoPath 2003

Summary: Learn how to use Microsoft Office InfoPath 2003 to create a reference implementation of an FIXML message, and examine the issues that emerge when translating an existing messaging protocol to XML by using the conventions of the W3C XML Schema specification. (20 printed pages)

Microsoft Corporation

February 2005

Applies to: Microsoft Office InfoPath 2003


FIXML Overview

The Microsoft implementation of the XML Schema specification in Microsoft Office InfoPath 2003 has valuable implications for users of industry-specific XML message sets. XML Schema is the World Wide Web Consortium (W3C) specification for building an abstract model of a message by using metadata (elements, attributes, and assemblies of these) to express the organization, structure, syntax, and meaning of a message. This makes it possible to generate an actual instance of a message directly from the schema model. Alternatively, if you have a message instance, you can use its schema definition to validate and determine the processing requirements of the message instance. After you define a message by using XML Schema, both people and computers can easily understand and use it. This can greatly reduce or eliminate the time-consuming and complex process of translating the specification for a messaging application into executable code. The significance of this becomes clear through a demonstration of how InfoPath empowers users to create sophisticated messaging applications based on complex message sets without having to write program code.

Many industry-specific initiatives are in place or underway to define and codify common, standardized vocabularies and message sets by using the structures and data types defined by the W3C XML Schema specification. Many of these initiatives have no formal semantic precedents, while several them are being created from existing, operative languages. An example of the latter is FIXML, the XML version of the Financial Information eXchange (FIX) protocol. FIX Protocol, Ltd. (FPL), the organization that maintains FIX as an open standard, released the XML schemas for the FIXML message set in January 2004. In March 2004, the Chicago Mercantile Exchange (CME) became the first adopter of FIXML by specifying its use for the real-time Position Services it is starting to offer. The CME specification provided an opportunity to use InfoPath to create a reference implementation of a form-based application that generates FIXML Position Maintenance messages from the FIXML message schemas that could be submitted to the Chicago Mercantile Exchange.

FIX Background

Before we describe how the InfoPath forms were created, a brief overview of FIX will provide the context for appreciating the value of using XML for defining standardized message sets. FIX was created in 1994 by Fidelity Management and Research Company and Salomon Brothers, both of whom wanted to realize the benefits of electronic trading without being tied to the electronic trading systems of specific brokers. By creating a public-domain messaging protocol for equity trading, all buy-side and sell-side organizations could use it to facilitate an electronic trading arrangement with one another. The companies later formed the FIX Protocol, Ltd., organization to maintain FIX as an open standard. FIX has been continually extended to accommodate a diverse range of financial instruments and also the entire transaction life cycle, from pre-trade advertisements to post-trade settlement. It is widely used in the financial services sector.

Because the FIX message set reflects the requirements of many constituents, it is complex. Version 4.4 contains almost 100 different messages incorporating approximately 1000 field definitions and 24 component blocks: field sets organized by logical and related function.

FIX messages use a "tag=value" syntax to indicate the field definition and the variables used in the field. The tag is a FIX-defined number, and the value is the variable that identifies some aspect of a transaction. The following is a FIX message that illustrates this syntax.

8=FIX.4.1§9=154§35=6§49=BRKR§56=INVMGR§34=236§ 52=19980604-07:58:48§23=115685§28=N§55=SPMI.M§54=2§ 25=H§10=159§

Each tag=value pair is separated by a nonprinting delimiter (shown as "§" for illustration only). The tags 8, 9, 35, 49, 56, and 34 (representing BeginString, BodyLength, MsgType, SenderCompID, TargetCompID, and MsgSeqNum, respectively) with their corresponding values, are required fields that are part of the FIX Message Header component block. The value for tag 35 (MsgType) is 6, which identifies this message as being an "Indication of Interest" message. The sequential order of the tag=value pairs is not strict and is contingent upon the message being constructed.

The FPL organization published a series of five implementation guides that document the message, component block, and field definitions--as well as the instructions, values, rules, and contingencies for creating FIX messages. Consequently, anyone who wants to generate or consume FIX messages must invest significant work in negotiating this documentation, translating its contents into code that executes a desired function. The generated code is highly individualized based on one's skill set, choice of development tools, and the possibilities of the requirement being addressed. Typically, because of these idiosyncrasies, the generated code is not reusable for other purposes or by other programmers. Alternatively, one could buy someone else's code, but this can be costly for highly specialized applications such as FIX messaging.

While a standardized message set is undoubtedly valuable for making automated communication easier, if the instruction set (the semantic, syntactic, and conditional operatives) for generating or consuming messages is not intrinsic to the messages themselves, in a form that is readily available to both people and computers, the implementation process is always painstaking, highly specific, and localized. And because the deployment effort is not leveraged, the potential strategic value of standardization is not fully achieved.

Value of XML Schema

This is where XML, specifically XML Schema, provides significant value. Consider an actual example of how XML Schema creates efficiencies. Tables 1 and 2 illustrate the documentation for specifying the characteristics of Options instruments using the coding methodology defined by the ISO 10962 Classification of Financial Instruments (CFI) standard. The Chicago Mercantile Exchange's new Position Services requires CFI codes to identify Options and Futures instruments in Position Request and Position Maintenance Request messages.

Table 1. Definition for Options (code defined by character position)
Char 1 Product Type Char 2 Put/Call Char 3 Option Style Char 4 Underlying Char 5 Delivery Method Char 6 Standard/Non-Std (flexible)





X=Unknown (not applicable)



X=Unknown (not applicable)


D=Interest rate/notional debt sec








X=Unknown (not applicable)



X=Unknown (not applicable)

S=Standardized terms (maturity date, strike price, contract size)

N=Nonstandardized terms

X=Unknown (not applicable)

Table 2. Example codes as defined in Table 1
Code Description


Standardized Call Option.


Standardized Put Option.


Standardized Call Option on a Future.


Standardized Put Option on a Future.


Nonstandardized (flex) Call option on Future with European style expiration and cash delivery.


Nonstandardized (flex) Put option on Future with American style expiration and physical delivery.


Nonstandardized (flex) Put option on a stock with physical delivery (the expiration style is not specified, so it is assumed to be the market standard for flex options by default).


Nonstandardized (flex) Call option on an index with European style expiration and cash delivery.

It would take a lot of time and effort to create or modify an application that generates these CFI codes for use in a message or for executing process contingencies based on the codes received in a message. In addition, every developer would have to do this individually. As mentioned earlier, this is inefficient.

The following example shows an XML schema fragment that documents the construction of the CFI codes as precisely as the tabular documentation shown earlier. In this example, the XML Schema documentation presents the information in a structured format that is both comprehensible to people and readily usable by computers.

<?xml version="1.0"?>
<xsd:schema xmlns:xsd="">
. . .
   <xsd:element name="Options">
            <xsd:element name="ProductType" type="ProductTypeType"/>
            <xsd:element name="PutCall" type="PutCallType"/>
            <xsd:element name="OptionStyle" type="OptionStyleType"/>
            <xsd:element name="Underlying" type="OptionUnderlyingType"/>
            <xsd:element name="Delivery" type="DeliveryType"/>
            <xsd:element name="Terms" type="StandardNonStdType"/>
   <xsd:complexType name="ProductTypeType">
         <xsd:element name="Option">
               <xsd:restriction base="xsd:string">
                  <xsd:enumeration value="O"/>
   <xsd:complexType name="PutCallType">
      <xsd:element name="Put">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="P"/>
      <xsd:element name="Call">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="C"/>
      <xsd:element name="Other">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="M"/>
      <xsd:element name="Unknown">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="X"/>
   <xsd:complexType name="OptionStyleType">
      <xsd:element name="American">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="A"/>
      <xsd:element name="European">
            <xsd:restriction base="xsd:string">
               <xsd:enumeration value="E"/>
      . . . . . 
. . . .

Building an XML schema is the process of creating the metadata and structural components that in turn define and model the actual information being processed. The significant value of an XML Schema is that, once you have used it to program information, you can use and reuse the schema definition in any functional context, independent of any programming language or platform. This effectively eliminates the need to continually reinvent the computer-usable structure, syntax, and semantics of the information for use in an application.

Figure 1 shows a form created in InfoPath from this CFI code schema; you can see a tree-view representation of the form in the Data Source pane on the right side. Each of the CFI code-value fields in the form is an InfoPath drop-down list that is bound to the corresponding schema elements containing the enumerated code-values. The form lets the user select the appropriate CFI code-values for each field as obtained from the schema nodes. After populating the fields with their respective values, the code generates a concatenated set of the derived CFI codes obtained from the schema in the CFI Code Holder field. Then it automatically copies the contents of this field into the CFI code field of a Position Maintenance Request message form (described shortly).

The logic governing the display of the schema values in the form and the facilities for generating the concatenated CFI codes are InfoPath XML functions that do not require any procedural programming. By using the application-independent CFI code schema and the standards-based XML data manipulation capabilities of InfoPath, you could create a CFI code generator in a matter of hours. Additionally, because the InfoPath application processing logic is expressed in XML, you can reuse any aspect of the form logic in any other application that requires the generation of CFI codes.

Figure 1. CFI code generation form implemented in InfoPath

CFI code generation form in InfoPath

With this fundamental understanding of how InfoPath uses information defined in XML Schema to create a form application, we can describe the process of creating an InfoPath form that generates a complex FIXML message. However, we first have to describe the two different styles of creating an XML schema: document and data-dictionary.

Document-style schemas describe the form and content for a discrete message function or data set. They also contain a single root (top-level) element that identifies the particular function or information set that the schema defines, such as PurchaseOrder or CFICodes. A document-style schema should contain all the relevant metadata required to generate an instance of the document or to programmatically access the information defined in the schema.

The FIXML message schemas are organized in a data-dictionary style, instead of a document style. Data-dictionary-style schemas are composed of multiple files containing multiple schemas (that is, no single root element) within each file. The metadata is usually organized in a highly referential manner, with metadata objects in one schema being defined by objects in another schema. The fixml-positions-base schema file contains five high-level message definitions: AsgnRpt, PosMntReq, PosMntRpt, PosReq, PosReqAck, and PosRpt. "High-level" means that the message schemas are abstract; they present "metadata outlines" that contain objects that reference other metadata objects in external auxiliary schema files. XML Schema facilitates these referential relationships by using a schema "include" declaration that links one schema with another.

The following code shows the high-level schema model for a PosMntReq message. It identifies the element and attribute metadata tags that make up the message, and these reference various "types" (metadata objects) found in external schema files (fixml-components-base and fixml-fields-base). These object types (formatted in bold) specify the values you can use with the message tags. The object types may also reference additional tags in the message.

  <xs:schema xmlns=""
   elementFormDefault="qualified" attributeFormDefault="unqualified">
  <xs:include schemaLocation="fixml-components-impl-4-4.xsd" 
   xmlns:xs="" /> 
  <xs:group name="PositionMaintenanceRequestElements" 
  <xs:element name="Pty" type="Parties_Block_t" maxOccurs="unbounded" /> 
  <xs:element name="Instrmt" type="Instrument_Block_t" /> 
  <xs:element name="Leg" type="InstrmtLegGrp_Block_t" minOccurs="0" 
   maxOccurs="unbounded" /> 
  <xs:element name="Undly" type="UndInstrmtGrp_Block_t" minOccurs="0" 
   maxOccurs="unbounded" /> 
  <xs:element name="TrdSes" type="TrdgSesGrp_Block_t" minOccurs="0" 
   maxOccurs="unbounded" /> 
  <xs:element name="Qty" type="PositionQty_Block_t" maxOccurs="unbounded" 
  <xs:attributeGroup name="PositionMaintenanceRequestAttributes">
  <xs:attribute name="TxnTyp" type="PosTransType_t" use="required" 
   xmlns:xs="" /> 
  <xs:attribute name="Actn" type="PosMaintAction_t" use="required" 
   xmlns:xs="" /> 
  <xs:attribute name="OrigReqRefID" type="OrigPosReqRefID_t" 
   use="optional" xmlns:xs="" /> 
  <xs:attribute name="RptRefID" type="PosMaintRptRefID_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="BizDt" type="ClearingBusinessDate_t" use="required" 
   xmlns:xs="" /> 
  <xs:attribute name="SetSesID" type="SettlSessID_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="SetSesSub" type="SettlSessSubID_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="Acct" type="Account_t" use="required" 
   xmlns:xs="" /> 
  <xs:attribute name="AcctIDSrc" type="AcctIDSource_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="AcctTyp" type="AccountType_t" use="required" 
   xmlns:xs="" /> 
  <xs:attribute name="Ccy" type="Currency_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="AdjTyp" type="AdjustmentType_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="CntraryInstrctnInd" 
   type="ContraryInstructionIndicator_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="PriorSpreadInd" type="PriorSpreadIndicator_t" 
   use="optional" xmlns:xs="" /> 
  <xs:attribute name="ThresholdAmt" type="ThresholdAmount_t" 
   use="optional" xmlns:xs="" /> 
  <xs:attribute name="Txt" type="Text_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="EncTxtLen" type="EncodedTextLen_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute name="EncTxt" type="EncodedText_t" use="optional" 
   xmlns:xs="" /> 
  <xs:attribute use="optional" type="PosReqID_t" name="ReqID" /> 
  <xs:attribute use="optional" type="TransactTime_t" name="TxnTm" /> 
  <xs:complexType name="PositionMaintenanceRequest_message_t" final="#all" 
  <xs:documentation xml:lang="en">PositionMaintenanceRequest can be found in Volume5 of the specification</xs:documentation> 
  <xs:appinfo xmlns:x="">
  <xs:Xref Protocol="FIX" name="PositionMaintenanceRequest" 
   ComponentType="Message" /> 
  <xs:Xref Protocol="ISO_15022_XML" /> 
  <xs:extension base="Abstract_message_t">
  <xs:group ref="PositionMaintenanceRequestElements" /> 
  <xs:attributeGroup ref="PositionMaintenanceRequestAttributes" /> 
  <xs:element name="PosMntReq" type="PositionMaintenanceRequest_message_t" 
   substitutionGroup="Message" final="#all" 
   xmlns:xs="" /> 

Dictionary-style schemas are useful for modeling the logical organization of volumes of complex information, but typically they are not structurally viable for deployment within production applications. As stated earlier, it should be possible to generate an actual message instance from a schema model. However, this is only possible if there is a direct correlation between the schema model of the message and the message itself. If the schema model becomes too abstracted—that is, if the actual metadata needed to represent the information in an instance document is more than one reference step removed from its abstract schema definition—then it is not possible to generate an instance document directly from the high-level message schema. When you are faced with a data-dictionary-style schema organization, it is usually necessary to synthesize and extract the document-style schemas in order to be able to use the schemas in a functionally meaningful way, which can be a significant task.

Advanced Schema-Handling Capabilities of InfoPath

Anticipating the challenges of working with referential, data-dictionary-style schemas, InfoPath incorporates the following schema-handling capabilities:

  • The ability to load nested referential schemas when schema "include" declarations are embedded.

  • The ability to select and isolate a single root element and its respective schema objects from a data-dictionary-style schema with multiple root elements and references to objects in multiple auxiliary schemas.

  • The ability to access the enumerated values defined in auxiliary schema objects.

  • The ability to select only the required elements and attributes in a message.

When you have all the FIXML Schema files located in the same folder, you can create an InfoPath form by using the fixml-positions-base schema file as the main data source. At this point you can select one of the five high-level message schemas in the file to use as the root schema. A blank form template with a tree-view structure of the PosMntReq schema appears in its Data Source pane. InfoPath basically extracts a logical, document-style representation of the PosMntReq message schema from the fixml-positions-base schema file. By inspecting the data properties of the schema attributes and finding the enumerated values associated with these schema objects, you can see that InfoPath also imports the "included" schema files (fixml-components-base and fixml-fields-base) that contain these values. Figure 2 shows the PosMntReq document-style schema in the Data Source pane and the enumeration value details of the Pty.Sub@Typ attribute.

Figure 2. Schema Data Source and Enumeration Properties tab

Schema Data Source and Enumeration Properties

In creating the virtual document-style schema representation of the PosMntReq message, InfoPath correctly includes every required and optional element and attribute in the schema, all 100+ of which are represented in a generated instance document if created from the schema as is. This is clumsy and inelegant, because an actual production instance of a PosMntReq message requires only a small subset of the schema elements and attributes. This issue is resolved by the default-value-editing facility in InfoPath, which lets you deactivate any non-required elements and attributes so that they are not represented in an instance document generated from the schema. This is shown in Figure 3.

Figure 3. Data source default-value-editing facility

Data source default value editing facility

It is now possible to build the message-generation form from the FIXML PosMntReq message elements and attributes specified by the CME, and apply the business logic and rules that apply to them. In addition, you must create secondary data sources, in the form of XML documents, that contain the lookup values for the Instrument ID and CFI Code fields, which have also been loaded into the InfoPath form. Figure 4 shows the final form filled in with the appropriate relevant values.

You can create form fields in InfoPath in one of two ways: either by dragging an element or attribute from the node tree in the Data Source pane to the form and then binding it to a display control such as a text box, drop-down list box, or repeating section; or the reverse, by dragging a control to the form and binding it to a data-source object. InfoPath provides a palette of controls that accommodate the display and functional requirements of any XML schema behavior. For example, the Party Block in the PosMntReq schema is composed of a group of nested elements that are used to identify multiple parties involved in a transaction. These elements are nested because they have mutual dependencies and must repeat on the form as a group. InfoPath provides a repeating section control to facilitate this behavior.

Figure 4. Completed InfoPath form

Completed InfoPath form

Working with Display Values and Secondary Data Sources

After you position the field controls on the form and bind them to the schema objects, the next step is to associate display name values with the enumerated code values defined for certain schema attributes, so that users filling out the form can understand the choices. The Transaction Type (TxnTyp) and Instrument ID (Instrmt@ID) attributes--both of which contain enumerated values--provide two examples of how to do this. If you inspect the TxnTyp attribute properties, you will notice five enumerated values: the numbers 1 through 5. These codes correspond to the five Position Services transaction types that the CME supports: Exercise, Do Not Exercise, Position Adjustment, Position Change Submission, and Margin Disposition. Because this is a discrete set of fixed values, it makes sense to embed them directly into the Display Name drop-down list box control, which conveniently enables a form creator to associate and store display names for any enumerated code values that the schema defines for an attribute tag. This is shown in Figure 5.

Figure 5. Properties for a drop-down list box

Properties for a drop-down list box

The Instrmt@ID attribute identifies the products that can be traded on the CME, such as Currencies, Indices, and Commodities. Because these products are specific to the CME and are dynamic, the FIXML PosMntReq schema, which any trading organization can use, does not contain the enumerated codes for these products. Instead, the CME publishes these product codes separately. Because dozens of traded products can change periodically, one way to incorporate this dynamic information into the form is to create an XML file containing the product names with their respective identification codes and then import the file into InfoPath as a secondary data source. Figure 6 shows a fragment of this XML file and its tree-view representation in InfoPath as a secondary data source.

Figure 6. Product ID XML and its data source representation

Product ID XML and data source representation

The product names in the XML file provide the display values for the Instrument ID drop-down list box control, and the Product ID codes link to the Instrmt@ID attribute tag in the schema. You do this by using the InfoPath lookup value facilities found on the Data properties tab of a control. Figure 7 shows the Data tab of the drop-down list box control that is bound to the Instrmt@ID attribute tag in the main source schema. The XML file (CME Product Codes) is connected to the control and the schema attribute to which it is bound. You use an XPATH expression to link the name attribute in the file to the list box display and the ID attribute in the file to the ID attribute tag in the schema. When the form generates the message document, it contains an Instrmt@ID attribute tag=value instance such as <Instrmt ID="AD"/> where "AD" is the Product ID code for Australian Dollar. This procedure is similar to what was done to capture the CFI codes, using an additional form view to pick the multiple CFI code values, which were then concatenated into a single field.

Futures trading and options trading create complex transactions. The FIXML Position Maintenance Request messages reflect this complexity. Many message components are required to describe a transaction, and codified contingency rules and validation requirements must be incorporated in the construction of these messages. The following section describes two examples of these, along with the InfoPath facilities for constructing and applying complex contingency rules and validation functions. These rules and functions govern the behavior of the form, and in turn constrain the values that the message can generate.

Figure 7. Connecting the Instrument control to the product codes

Connecting Instrument control to product codes

Using Conditional Formatting and Rules

The first example concerns the construction of a Party Block in the PosMntReq message. The Party Block, as mentioned earlier, is used to identify the parties involved in a trade, which at a minimum include the following entities: a Clearing Organization, a Clearing Member Firm, and a Trading Firm identified as itself or by a specific Position Account managed by the Trading Firm. The Trading Firm or Position Account is further qualified by noting whether the trade is being executed on behalf of a Customer of the Trading Firm or for the Trading Firm itself (that is, the "House").

In the PosMntReq schema, the Party Block is defined as a complex element (Pty) that contains the following attributes:

  • Pty@ID a unique CME identifying code assigned to each Party.

  • Pty@R the Roles of the respective Parties to the trade. You must specify the following enumerated values in the Party Block with this attribute: 4 for the Clearing Member Firm, 21 for the Clearing Organization, and 1 or 38 for the Trading Firm or Position Account, respectively.

  • Pty@SRC a source ID that is an enumerated value. This attribute is not used in the CME PosMntReq implementation.

In addition, the Pty element contains a nested child element (Sub) that contains the following attributes:

  • Sub@ID an enumerated value of 1 for Customer or 2 for House.

  • Sub@Typ a fixed value of 26 indicating that the Sub@ID values specify Account Types.

The attribute values of the Sub element are used only when the Pty@R value is either 1 or 38; that is, for further qualifying for whom the trade is being executed by the Trading Firm. The Party Block is repeated, in order to identify the multiple parties involved in a trade. The following is a PosMntReq message fragment showing a Party Block instance that contains all the required Party information. The Sub element attributes are empty when the R attribute in the Pty element does not contain a value of 1 or 38. The empty Sub element is generated nevertheless, because as a child of the Pty element it inherits the repeating behavior of its parent.

<Pty ID="600" R="4"/>
<Sub ID="" Typ=""/>
<Pty ID="CME" R="21"/>
<Sub ID="" Typ=""/>
<Pty ID="500" R="38"/>
<Sub ID="2" Typ="26"/>

InfoPath provides several validation and constraining functions that can ensure that all the required Party Roles are accounted for in a PosMntReq message. The Sub element attributes are used only together with the Trading Firm or Position Account Roles. Two methods are presented here for constraining the use of the Sub element attributes. The first method uses the conditional formatting facility of InfoPath, which is shown in Figure 8.

Figure 8. Conditional formatting constraints

Conditional formatting constraints

As you can see, if two conditions are met (R is not equal to 1 or R is not equal to 38), the control for the Sub ID and Sub Type fields is disabled, meaning that you cannot enter values in these form fields and the default values are defined as empty. If a user enters the values of 1 or 38 for a Role, the Sub ID and Sub Type fields are enabled for that specific Role iteration. The values of 1 or 2 are available in the Sub ID field and a fixed default value of 26 appears in the Sub Type field. These condition statements are also used to define rules and validation requirements. InfoPath provides many predefined conditional expressions that you can apply to fields and sections, and also to other expressions and form variables.

The second method of constraining values is to establish one or more rules that set the values for one field based on the values entered in another field. Figure 9 shows the defined rules and one of the actions specified for a Rule condition of the Role attribute. You may notice three rules that automatically set values for the Sub Type attribute field based on values entered in the Role attribute field.

Figure 9. Constraining rules defined for the Role attribute

Constraining rules defined for the Role attribute

Using Scripting to Constrain and Validate Values

InfoPath has highly developed, built-in capabilities for defining and setting complex behavioral contingencies among form objects. These capabilities can address most functional requirements that would ordinarily require programmatic coding. However, certain requirements always fall outside the predefined capabilities of any application. For these situations, InfoPath provides built-in scripting or the ability to use managed code in Microsoft Visual Studio .NET to control a form's behavior.

The CME PosMntReq message has such a requirement: the Clearing Date (BizDt attribute) for any request must be the current or next business day only; any other date invalidates the request. InfoPath does not have a predefined formula or function that you can use in a rule expression to express this logic. Therefore, you must program this date logic using the InfoPath scripting editor and bind the logic to the BizDt attribute field. The Microsoft Visual Basic script for this logic is shown here.

' The following function handler is created by Microsoft Office InfoPath.
' Do not modify the name of the function, or the name and 
' number of arguments.
' This function is associated with the following field or group 
' (XPath): /ns1:PosReq/@BizDt
' Note: Information in this comment is not updated after the 
' function handler is created.
' CJS Note: This Sub verifies that the Clearing Date is today or tomorrow
Sub msoxd__BizDt_attr_OnBeforeChange(eventObj)
' Write your code here
' Warning: ensure that the constraint you are enforcing 
' is compatible with the default value you set for this XML node.

' If no setting return immediately
If (eventObj.Site.nodeTypedValue = "") Then
   Exit Sub
End If

' If the new setting cannot be a Date return immediately with an error
If (Not IsDate(eventObj.Site.nodeTypedValue)) Then

   eventObj.ReturnMessage = "Date not Valid: Use YYYY-MM-DD or MM/DD/YY"
   eventObj.ReturnStatus = false

   Exit Sub
End If

Dim eventDate
eventDate = eventObj.Site.nodeTypedValue

Dim today
today = Date

Dim ddif 
ddif = DateDiff("d", today, eventDate)

If (ddif <> 0 AND ddif <> 1) Then
   'eventObj.ReportError eventObj.Site, "Date NOT Valid - Must be 
   'Today or Tomorrow", false
   'MsgBox "Date NOT Valid - Must be Today or Tomorrow"
   eventObj.ReturnMessage = "Date not Valid: Must be today or tomorrow"
   eventObj.ReturnStatus = false
End If

End Sub

You must apply an additional level of validation to the Party Block, to ensure that the user filling out the form enters all the required Party ID/Role values. This validation function is also implemented as the next step, using the InfoPath scripting facility. The validation routine checks if all the Role values that are entered match the required values. If they do not, the user receives an error message and the form is not submitted. This validation function is incorporated with other validation routines and bound to the Validate button on the form.

Using a Web Service in InfoPath

InfoPath can access and use as a secondary data source any remote application exposed as an XML Web service. This capability is useful for generating a unique internal message sequence number as specified by the FIXML implementation guide for the PosMntReq message. It is a fair assumption that in an actual production environment where multiple traders are generating PosMntReq messages, the message sequence number functions as an operational control mechanism. As such, it would not be generated locally on a workstation. Because the purpose of this reference implementation is to show you how to apply XML technologies to real-world production requirements, this assumption provides the rationale for using a centrally accessible Web service to generate sequence numbers used to identify message instances created on each workstation. The following example shows how to do this by using ASP.NET code running as a Web service on Internet Information Services (IIS).

// Service1.cs

using System;
using System.Collections;
using System.ComponentModel;
using System.Data;
using System.Diagnostics;
using System.Web;
using System.Web.Services;

namespace CMESeqNumNETService

    /// <summary>
    /// Summary description for Service1.
    /// </summary>
    public class Service1 : System.Web.Services.WebService
        private static int sdata = 3000;
        public Service1()
            //CODEGEN: This call is required by the ASP.NET Services Designer
        /* Component Designer generated code section goes here */
        public int getCMESeqNum()
            return sdata++;
    }   // end class Service1

}        // end namespace

Figure 10 shows the InfoPath data source binding connection from the form sequence number field to the Web service operation.

Figure 10. Data source connection to a Web service

Data source connection to a Web service

After you apply the rules and validation logic, the final step is to create a Submit function that generates the message instance document and transmits it through a transport mechanism. InfoPath provides the following Submit options: E-mail, Web service, SharePoint Form Library, Web Server (HTTP), Custom Submit Using Form Code (Scripting), and Custom Submit Using Rules. The following code shows an actual PosMntReq instance document generated from the InfoPath form described here.

<?xml version="1.0" encoding="UTF-8"?>
<?mso-infoPathSolution solutionVersion="" productVersion="11.0.6250" 
PIVersion="" href="file:///C:\FIXMLProject\CME%20PosMntReq\CME%20PosMntReq.xsn" 
   fixprotocol-org-FIXML-4-4" language="en-us" ?>
<?mso-application progid="InfoPath.Document"?>
<ns1:PosMntReq TxnTm="2004-06-08T09:42:26" Actn="1" SetSesID="INTRA" 
   TxnTyp="1" BizDt="2004-06-08" AcctTyp="" 
ReqID="42:261EXR" AdjTyp="" Acct="" 
    <ns1:Hdr SeqNum=""></ns1:Hdr>
    <ns1:Pty R="4" ID="CME">
        <ns1:Sub ID="ABC" Typ="26"></ns1:Sub>
    <ns1:Pty R="21" ID="CME">
        <ns1:Sub ID="" Typ="26"></ns1:Sub>
    </ns1:Pty><ns1:Pty R="1" ID="600">
        <ns1:Sub ID="2" Typ="26"></ns1:Sub>
        ns1:Instrmt ID="BP" StrkPx="55.00" Exch="CME" MMY="200411" 
    <ns1:Undly ID="" StrkPx="" MMY="200412" CFI=""></ns1:Undly>
    <ns1:Qty Stat="0" Long="550.00" Typ="TQ" Short=""></ns1:Qty>


Any functional aspect of this FIXML messaging reference implementation can be easily accessed, understood, and reused. This exercise shows that any developer faced with an FIXML messaging project could immediately and significantly improve his or her development efficiencies by taking advantage of the schema handling capabilities of InfoPath.

InfoPath is emblematic of the XML development tools used for creating Service Oriented Architecture (SOA) applications. In the SOA paradigm, an application is no longer an opaque and abstract implementation mechanism. It is now an exposed, orchestrated workflow of services and messages where the declarative properties of rich (XML) documents are acted upon and processed in various places and times. The substantial value of SOA applications is their openness and agility. Anyone who wants to know the technologies and methodologies of the SOA development paradigm should consider starting with InfoPath.

Additional Resources