The following factors are important when exporting and importing wire formats from an existing Formatter database for use in an Unwired Orchestrator business process.
Before you can import wire formats, you must create an export file containing the Formatter database metadata that defines the custom wire formats you will be using at runtime. This file must contain the input format that you plan to use to define a notification service,which will parse custom wire format messages, or both the input format and associated output format if you will be defining a one-way service, which will serialize a custom wire format messages to an output queue.
To ensure that all formats are XML schema-compliant, you must use the [-N] parameter when creating the export file. This parameter enables the normalization of wire formats by scrubbing all special characters for compliancy. This can be done using the Formatter GUI: select the Normalize option from the export screen. It can also be done using the NNFie tool from the command line: use the [-N] parameter.
Note: The version of Formatter that is packaged with Unwired Orchestrator provides these options.
For more information on exporting wire formats, see Formatter online help.
Although the export process allows you to export an entire set of formats into one NNFie file, the import process requires that you execute the process for each input format plus associated output formats that you want to bring into your project. The result is the creation of an .xsd file that conforms to each input format. This .xsd file is used to define the Notification or One-Way services needed in your business process.
For more information on importing, see Importing Wire Formats.
To properly parse the data contained in inbound wire formats, do one of the following:
In the header of each inbound message, specify each imported format name in the OPT_MSG_TYPE property.
In the inbound transport
resource configured under your instance, specify a default value for each
format name in the OPT_MSG_TYPE property.
- In the header of each inbound message, specify the input format name
in its original non-normalized version in the OPT_MSG_TYPE property.
- In the Optional properties of the inbound transport resource configured
under your instance, specify the default value for the format name in
the OPT_MSG_TYPE property.
Note: You must specify the normalized format name as it appears in the .nnfie file.
To properly reformat the data contained in outbound wire formats, note the following when defining One-Way services in your business process:
In the Message Schema screen, use the .xsd file that corresponds to the input format, derived from the .nnfie file during the importing process.
In the Message Element screen, specify the top-level format.
Note: There is one .xsd file for each input format that was imported.
In the Wire Format Details dialog box, specify Custom Wire Format as the wire format type, and select the appropriate output format as the Output Format Name.
Note: A One-Way service that outputs a custom wire format may be understood as a service invocation, which requires two input properties: the .xsd file, which describes the structure of the data, and the target output format.
The Message Options screen allows you to specify optional values for the OPT_MSG_TYPE or OPT_APP_GROUP header properties, which may be used by downstream processes that receive the outbound custom wire format message. Note that user-defined name-value pairs may also be defined here and will then be added to the headers of outgoing messages.
If you plan to use WebSphere MQ messaging service to transport inbound or outbound wire formats, specify the following information when configuring your transport resources:
Set the MQ RFH version property to 1 or 2.
For RFH2 headers, set the WebSphere MQ Session Instance Map Mode property to TRUE.