The following section provides a comprehensive reference for all the predefined preparsers that are supplied with iWay Service Manager.
Preparser Name |
Class Name |
Streaming? |
Description |
---|---|---|---|
Append |
XDAppend |
No |
Used for appending text to an existing flat file. |
C Char Filter |
CCharFilter |
No |
Eliminates control characters from an incoming message. |
Char Repl |
XDCharRepl |
No |
Performs character replacements in the incoming document. |
Cross-Origin Resource Sharing |
XDCors |
No |
Implements the same functionality as the Cross-Origin Resource Sharing Service. |
Delimited Value |
XDDelVal |
No |
Delimited value handler. |
Delimited Value Stream |
XDDelValStream |
Yes |
Streamable delimited value handler. |
EDIFACT Batch Splitter Preparser |
XDEDIFACTBatchSplitter |
No |
Splits EDIFACT input files that contain multiple transactions or envelopes. |
EDI Batch Splitter |
XDEDIBatchSplitter |
Yes |
Splits a batch of EDI documents. |
EDIFACT |
XDEDIFACTPreParser |
No |
Accepts a % in the template name, which is filled in by message type. |
EDIX12 |
XDEDIpreParser |
No |
After a batch of EDI messages is split, this preparser converts each EDI message into XML format. |
EDIX12 Splitter Preparser |
EDISplitPP |
Yes |
Parses an EDI input file that contains one or more interchanges (ISA) and multiple documents, and creates multiple XML output files. For more information, see the iWay Integration Solution for EDI User's Guide. |
EDIX12 XML Validator |
XDXMLEDIValidator |
No |
Takes EDI XML as input and returns that input with the structural errors section added to be processed by the appropriate rule. |
En Tag |
XDEnTag |
No |
Surrounds the incoming message with a designated tag. |
Error Filter |
ErrorFilter |
No |
Obtains the original input document from the error document. |
Excel |
XDExcelpreParser |
No |
Transforms an Excel worksheet into an XML formatted document. |
Extract Preparser |
XDExractPreparser |
Yes |
Decompresses compressed files. |
Flat Stream |
XDFlatStreamPreParser |
Yes |
Splits non-XML messages that are to be split on a recognized character. |
HIPAA Batch Splitter |
XDHIPAABatchSplitter |
No |
Splits a batch of HIPAA documents. |
HIPAA Preparser |
XDHIPAAPreParser |
No |
Transform a HIPAA document into a HIPAA XML document. |
HIPAA Splitter Preparser |
HIPAASplitPP |
No |
Parses a HIPAA input file that contains one or more interchanges (ISA) and multiple documents, and creates multiple XML output files. For more information, see the iWay Integration Solution for HIPAA User's Guide. |
HTTP |
XDHTTPpreParser |
No |
Transforms a key=value query string into an XML string with the POST action as the root. |
HTTP Multipart |
XDHTTPMultipartPreparser |
No |
Transforms a key=value query string into an XML string with the POST action as the root. |
Inflate |
XDInflate |
No |
Inflates data produced by the deflate preemitter. |
JMS Object Preparser |
XDJMSObjectPreParser |
No |
Used to convert a JMS ObjectMessage to a suitable iSM message. |
Legacy Record |
LegacyRecordPreparser |
No |
Converts an incoming legacy flat file (copybook) into an XML file. For more information, see the iWay Transaction Adapter for CICS User's Guide. |
Multi Part |
XDMultiPart |
No |
Divides multipart documents for later use. |
Multi Part for NHTTP |
XDMultiPartForNHTTP |
No |
Divides multipart documents into body and attachments. |
PgpDecrypt |
PGPDecrypt |
No |
Decrypts an incoming message on the channel into the original unencrypted format. |
Safestore |
XDSafestorePreparser |
No |
Stores incoming HTTP messages. By default, messages are written to the disk. |
SOAP |
XDSOAPPreParser |
No |
Accepts SOAP message from any JMS listener. |
SREG Preparser |
XDSREGPreparser |
No |
Sets one or more special registers of a given type. |
SWIFT ACK |
SwiftBPP |
No |
Transforms MT021 Systems Messages to XML-formatted documents. For more information, see the iWay Integration Solution for SWIFT User's Guide. |
SWIFT Batch Splitter |
XDSWIFTBatchSplitter |
Yes |
Splits the input stream and produces groups of byte[]'s as per the predefined splitting logic. For more information, see the iWay Integration Solution for SWIFT User's Guide. |
SWIFT System Message |
XDSWIFTSysMsgPreParser |
No |
Transforms SWIFT User-to -System and System-to-User FIN Format Messages to XML-formatted documents. For more information, see the iWay Integration Solution for SWIFT User's Guide. |
XDSWIFT |
XDSWIFTpreParser |
No |
Accepts a % in the template name, which is filled in by message type. For more information, see the iWay Integration Solution for SWIFT User's Guide. |
XML Split |
XDXMLSplit |
No |
Splits an incoming XML document based on an XPATH value. |
XML Stream |
XDXMLStreamPreParser |
Yes |
Accepts an input file containing multiple XML documents and creates single XML documents from the original input file. |
Syntax:
com.ibi.preparsers.XDAppend
Description:
The Append preparser is used to append text to an existing flat file. This preparser should not be the last in the chain before a route is called. You can use the En Tag preparser to enclose the flat appended text into an XML structure or use iWay Transformer to convert a flat file to XML format.
In a use case scenario, the Append preparser is useful when two flat files need to be appended. However, to convert to XML, an additional preparser, such as En Tag ,should be used in order to process the flat file through the channel.
Parameters:
Parameter | Description |
---|---|
Prefix | Adds text to the head of the incoming document. |
Suffix | Adds text to the tail of the incoming document. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
This Append preparser adds a prefix (test) to the incoming flat document. To convert this document to an XML file, you could use the En Tag preparser.
Syntax:
com.ibi.preparsers.CCharFilter
Description:
The C Char filter preparser is used to remove control characters from an incoming message.
In a use case scenario, the C Char filter preparser can be used when an incoming message is unformatted and contains carriage returns. The C Char filter preparser can remove the carriage return and tab fields before sending it to a message flow for further processing.
Parameters:
Parameter | Description |
---|---|
Linefeed * | Indicates whether linefeed characters (\r) need to be removed. |
Carriage Return * | Indicates whether carriage returns (\n) need to be removed. |
Tab * | Indicates whether tab characters (\t) need to be removed. |
End Of File * | Indicates whether DOS end of file (0x1a) characters need to be removed. |
Bell * | Indicates whether bell (0x07) characters need to be removed. |
Control | |
Replace With * | Indicates whether the removed characters are replaced with a space, period, or none (remove). |
Example:
In the following example, the C Char filter preparser is used to create a list of travel items, which were originally listed in a file separated by a line feed, into a list containing all the items on a single line.
The configuration parameters pane opens.
The name and description pane opens.
suitcase toothbrush travel case comb soap
When this input document is processed by the channel, an output document (for example, travellist_out.txt) is generated with the following contents:
suitcase toothbrush travel case comb soap
Syntax:
com.ibi.preparsers.XDCharRepl
Description:
The Char Repl preparser is used to perform character replacements in an incoming document.
In a use case scenario, if a name is misspelled in an incoming document as Rom instead of Tom, then the character R could be replaced with T in this document. It is analogous to the find and replace function that can be found in most word processing applications.
Parameters:
Parameter | Description |
---|---|
Input * | String of individual characters to replace. |
Replace with * | String of characters to replace input with. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
<a> <t> <b name="rom"> <c>value of input element</c> </b> <b name="rom2"> <c>value of input element</c> </b> </t> </a>
When this input document is processed by the channel, an output XML document is generated with the following contents:
<?xml version="1.0" encoding="ISO-8859-1" ?> <a><t><b name="tom"><c>value of input element</c></b> <b name="tom2"><c>value of input element</c></b></t></a>
Syntax:
com.ibi.preparsers.XDCorsPreparser
Description:
This preparser implements the same functionality as the Cross-Origin Resource Sharing Service (com.ibi.agents.XDCorsAgent). For more information, see Cross-Origin Resource Sharing Service (com.ibi.agents.XDCorsAgent).
The preparser causes an error if the returned edge would be anything other than success.
Syntax:
com.ibi.preparsers.XDEDIFACTPreParser
Description:
After a batch of EDIFACT messages are split, the EDIFACTPreParser converts each EDIFACT message into XML format. For more information on how to configure the EDIFACTPreParser, see the iWay Integration Solution for UN/EDIFACT User's Guide.
Syntax:
com.ibi.preparsers.XDEDIpreParser
Description:
After a batch of EDI messages is split, the EDIX12PreParser converts each EDI message into XML format.
Note: The EDIX12PrePreparser is deprecated. As an alternative it is recommended to use the EDIX12SplitterPreParser (EDISplitPP)/
Syntax:
com.ibi.preparsers.XDXMLEDIValidator
Description:
The EDIX12 XML Validator preparser takes EDI XML as input and returns that input with the structural errors section added to be processed by the appropriate rule.
Syntax:
com.ibi.preparsers.XDEnTag
Description:
The En Tag preparser surrounds the incoming message with a designated tag. Optionally, it passes on the incoming message as CDATA to the tag. Additional features allow configuration of attributes including source, message ID, and correlation ID.
In a use case scenario, the En Tag preparser can be used when a flat file needs to be converted into an XML file without changing the format of the flat file (using the entire content of the flat file as is). For instance, if a flat file contained a list of names separated by carriage returns, this preparser can be used to convert the file to XML format.
Parameters:
Parameter | Description |
---|---|
Tag * | Name of the tag used to surround the input. |
Cdata | If set to true, the input is enclosed as a CDATA value. |
Protocol | Determines whether to Include the protocol as an attribute. |
Source | Determines whether to Include the source as an attribute. |
Message ID | Determines whether to Include the message ID as an attribute. |
Correlation ID | Determines whether to Include the correlation ID as an attribute. |
Entity replace | If set to true, the input will be XML entity replaced. |
Base64 | Determines whether the content should be encoded into base64 form. |
Result Form | Specifies the type of output that is required. Select parsable or tree from the drop-down list. |
Call at EOS? | In streaming a last call is made after the last document. Determines whether this service should be called. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
Note: This preparser can also be used in conjunction with the Append preparser to illustrate its use.
When this input document is processed by the channel, the contents are appended and enclosed. The following XML output document is generated:
<?xml version="1.0" encoding="ISO-8859-1" ?><testroot>testappend</testroot>
Syntax:
com.ibi.preparsers.ErrorFilter
Description:
The Error Filter preparser operates on iWay error documents. Error documents are a standard by which iWay Service Manager reports errors back to the user. These documents contain the complete incoming message associated with an error. The preparser extracts the original message and passes it into the system for processing. Messages that are identified as not being error documents are passed along without any modifications.
In a use case scenario, the Error Filter preparser can be used to obtain the original document from an error document if the user needs to retest a component, but does not have the original document.
Example:
The configuration parameters pane opens.
<?xml version="1.0" encoding="ISO-8859-1" ?> <eda> <error timestamp="2009-05-07T20:55:30Z" source="com.ibi.agents.XDSQLAgent" stage="AGENT">com.microsoft.sqlserver.jdbc.SQLServerException: Invalid column name 'ragv'. <data type="xml"><?xml version="1.0" encoding="ISO-8859-1"?><test> This is a detag preemitter test </test> </data> </error> </eda>
When this input document is processed by the channel, the following XML output document is generated:
<?xml version="1.0" encoding="ISO-8859-1" ?><test>This is a detag preemitter test </test>
Syntax:
com.ibi.preparsers.XDExcelpreParser
Description:
The Excel preparser transforms an Excel worksheet into an XML formatted document. If required, this preparser uses the header row in the Excel worksheet as XML tags for the data elements.
In a use case scenario, the Excel preparser is useful when data in Excel must be transformed into XML.
Note: When using the Excel preparser to convert an Excel document to XML, it changes the dates from mm/dd/yyyy to mm/dd/yy. For example, if the Excel document has a cell format of Date *03/14/2001 (with an asterisk), the date will convert to 03/14/01. If the cell format is Date 03/14/2001 (without an asterisk), it will convert to the proper format of 03/14/2001 . The image below shows the date selection that will not keep the original format and the date selection that will keep the original format.
Parameters:
Parameter | Description |
---|---|
hasheaders | Determines whether the contents of the first row are the names to be used for subsequent rows. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
Character Use Return type Example | Use | Example |
---|---|---|
y | year | yyyy=2006, yy=06 |
M | Month of year | MM=06, MMM=Jun, MMMM=June |
w | Week in year | 26 |
W | Week in month | 26 |
h | Day in year (Julian) | 26 |
h | Day in month | 26 |
h | Day of week | 26 |
h | Day of week in month | 26 |
The output document [document_out]*.xml will have the following format:
<?xml version="1.0" encoding="ISO-8859-1" ?> <workbook> <ism.pdf> <row> <RowNumber>2</RowNumber>
<Character_Use_Return_type_Example>y</Character_Use_Return_type_Example> <Use_>year</Use_> <Example>yyyy=2006,yy=06</Example> </row> <row> <RowNumber>3</RowNumber>
<Character_Use_Return_type_Example>M</Character_Use_Return_type_Example> <Use_>Month of year</Use_> <Example>MM=06, MMM=Jun, MMMM=June</Example> </row> <row> <RowNumber>4</RowNumber>
<Character_Use_Return_type_Example>w</Character_Use_Return_type_Example> <Use_>Week in year</Use_> <Example>26</Example> </row> <row> <RowNumber>5</RowNumber>
<Character_Use_Return_type_Example>W</Character_Use_Return_type_Example> <Use_>Week in month</Use_> <Example>26</Example> </row> <row> <RowNumber>6</RowNumber>
<Character_Use_Return_type_Example>h</Character_Use_Return_type_Example> <Use_>Day in year (Julian)</Use_> <Example>26</Example> </row> <row> <RowNumber>7</RowNumber>
<Character_Use_Return_type_Example>h</Character_Use_Return_type_Example> <Use_>Day in month</Use_> <Example>26</Example> </row> <row> <RowNumber>8</RowNumber>
<Character_Use_Return_type_Example>h</Character_Use_Return_type_Example> <Use_>Day of week</Use_> <Example>26</Example> </row> <row> <RowNumber>9</RowNumber>
<Character_Use_Return_type_Example>h</Character_Use_Return_type_Example> <Use_>Day of week in month</Use_> <Example>26</Example> </row> </ism.pdf> </workbook>
Syntax:
com.ibi.preparsers.XDExtractPreparser
Description:
Compressed files, such as .zip or TAR/GZ, can be decompressed using this preparser. Each entry in the compressed file is presented sequentially to the channel for processing. For example, a .zip file containing a group of related HL7 documents could process those documents one at a time as if they had arrived on the channel individually. All entries in the file are presented on the same thread.
Parameters:
Parameter | Description |
---|---|
Data | Each decompressed file is presented as a Service Manager document. |
Signal | The signal option causes the preparser to decompress the entry to a file system location, and present the location in a Service Manager Signal document and Special Registers. The application can elect to read the file if needed using agents such as XDFileOpsAgent and XDFileReadAgent. The channel should delete the file as part of processing the file. |
Stream | The preparser can emit a decompressed file in stream format. This presents a single access stream for each entry in the archive (even if the archive is a single compressed file). |
The preparser appears as any streaming preparser with an end of stream signal (<batch>EOT</batch>) document following the final decompressed file. The EOS signal of the preparser is not associated with the individual file(s) streams. Rather, the EOS signal represents the end of the decompression process of the archive file. The channel may elect to handle the end of stream if desired.
Special Registers
The following table lists and describes the Service Manager Special Registers that are set by the preparser with each decompressed entry.
Special Register Name | Description |
---|---|
archive | Name of the archive file. |
source | File name and directory path. If you select the Signal option, the file will be decompressed to the file system with Service Manager, especially if the register contains the absolute path of the file. However, if you select either the Data or Stream option, then the register will represent the directory structure within the archive file. |
parent | Directory that contains the file (or missing if there is no parent directory) |
basename | The file name without extension. |
extension | Only the file extension. |
filename | The file name and extension without a parent directory. |
msgsize | Size of the decompressed file. |
Notes:
To maintain backwards compatibility for simple .zip compressed files, the File listener can be used to decompress this type of file upon receipt of the file. However the File listener is not capable of decompressing anything other than .zip files.
This preparser is a streaming preparser. What this means is that one file (in this case the .zip archive) is broken down into separate documents each representing a file contained in the archive. For example, if the user is configuring a File listener channel to process the archive file and uses the default.outlet as the channel outlet, then each extracted file is emitted to the configured Destination by default and will have the name of the archive (for example, archive.tar) not the name of the archive's extracted file.
If the user is required to extract the files to the file system of iSM using the output.default channel outlet, then the File listener's configuration for Destination must be configured, as shown in the following image.
The back-tick character (`) is used by iSM to delay the evaluation of the iFL function SREG until runtime. If the back-tick character is excluded, then the iFL evaluation is performed when the listener is configured. This is very important to remember because the SREG source is only set when the .zip archive file is extracted. It is also important to remember the setting of the Data Format parameter for this preparser and how the iSM SREGs are set:
Data Format | Special Register |
---|---|
data | source This SREG contains the archived file's path which included the archived file's directory structure. Therefore, if the archived file is data/file1.xml when iSM evaluated the iFL c:/temp/SREG(source), the resulting Destination path is returned as c:/temp/out/data/file1.xml. |
stream | source Like data this SREG contains the archived file's path which included the archived file's directory structure. Therefore if the archived file is data/file1.xml when iSM evaluated the iFL c:/temp/SREG(source), the resulting Destination path is returned as c:/temp/out/data/file1.xml. |
signal | source Unlike data and stream this SREG contains the actual path to the extracted archived file on the iSM file system. Using the iFL c:/temp/SREG(source) will generate an invalid destination. |
filename This SREG contains the extracted file's name and extension (if one exists) only. If the user wants to save the iSM Signal document in the Destination, then the iFL must be changed to c:/temp/out/SREG(filename) when iSM evaluates the iFL and returns c:/temp/out/file1.xml. |
The user can also provide an outlet that contains the File emitter. Using an outlet other than output.default overrides the Destination parameter in favor of the outlet's File Emitter configuration. The use of iFL and SREGs would mirror the File listener's Destination parameter without the back-tick character. The back-tick character is not required at this point because the iSM SREGs already reflect the information about the archive's extracted file.
Configuring the Extract Preparser
The following image shows the configuration screen for the Extract preparser.
The following table lists and describes the options in the Data Format drop-down list.
Parameter | Description |
---|---|
Data | The decompressed data is moved directly into the document. This option takes up the most memory and may not be appropriate for decompressed files larger than a few megabytes. |
Signal | The decompressed file is stored on the file system of Service Manager and a Signal document containing the information and location of the file is created. This option takes up only the amount of memory needed for the signal document itself. You can then obtain the location of the file from the Signal document. Note: You are responsible for deleting (if desired) the decompressed archive file(s). |
Stream | The decompressed InputStream of the file is stored in the document. A Signal document is created containing information about the decompressed file. This option takes up only the amount of memory needed for the signal document itself and the data stream of the decompressed file. |
Syntax:
com.ibi.preparsers.XDEDIFACTPreParser
Description:
The HIPAAPreParser transforms a HIPAA document into a HIPAA XML document.
Note: The HIPAAPreParser is deprecated. As an alternative, it is recommended to use the HIPAASplitterPreParser (HIPAASplitPP)
Syntax:
com.ibi.preparsers.XDHTTPpreParser
Description:
The HTTP preparser transforms a key=value query string into an XML string with the GET action as the root. This preparser can be used to construct an XML document with the HTTP parameters that are being passed as a query string. The HTTP preparser can only be used with an HTTP listener.
In a use case scenario, if you need to generate an XML document with the HTTP request parameters, the HTTP preparser can be used to transform the HTTP GET request for a web application.
Example:
The configuration parameters pane opens.
<html xmlns="urn:schemas-microsoft-com:xslt"> <head> <title>Posting a File</title> </head> <body> <form id ="f" action="http://TestMachine:8080/newproject/postfile60.html" enctype="multipart/form-data"> <input type="file" name="fdata"/> </form> </body> </html>
http://informat-2a8d8e:9984/index.html?value1=4&value2=two
The following output is obtained:
<?xml version="1.0" encoding="ISO-8859-1" ?> <post> <value1>2</value1> <value2>two</value2> </post>
Syntax:
com.ibi.preparsers.XDInflate
Description:
The Inflate preparser inflates data produced by the Deflate preemitter.
An example where the Deflate preemitter could be used is when a large file (for example, 5 MB in size) must be sent by email using an Email emitter. In this scenario, the destination email server does not accept messages that are greater than 3 MB in size. The Deflate preemitter could be used before the Email emitter to send the message in an email. The Inflate preparser could be used once the email is read through an Email listener and subsequently picked up by the Inflate preparser in the channel.
Example:
The configuration parameters pane opens.
The input file for this channel must be a deflated (compressed) document.
Syntax:
com.ibi.preparsers.XDJMSObjectPreParser
Description:
The XDJMSObjectPreParser is used to convert a JMS ObjectMessage to a suitable iSM message. While the server can deal with most message type automatically, it needs application programming assistance to deal with the generic ObjectMessage. This preparser or an extension of it must be invoked by the channel to manage the ObjectMessage retrieved from the JMS Queue or Topic.
Parameters:
Parameter | Description |
---|---|
Root Tag | Root tag of the output XML document. If not specified, the channel name will be used. |
Example:
This JMS Object preparser will produce an XML document representing the ObjectMessage that was retrieved from the JMS Queue or Topic.
Below is a sample document returned by the XDJMSObjectPreParser.
<JMSOBJ type="object"> <JMSOBJ> <object name="test.TestSerial"/> <test.TestSerial userObjectConversion="default"> <fields> <field name="serialVersionUID">private static final long TestSerial.serialVersionUID</field> <field name="count">private int TestSerial.count</field> </fields> <methods> <method name="bumpCount">public void TestSerial.bumpBount()</method> <method name="getCount">public int TestSerial.getCount()</method> </methods> </test.TestSerial> </JMSOBJ> </JMSOBJ>
For more information on the JMS Object preparser, see the iWay Service Manager Protocol Guide .
Syntax:
com.ibi.preparsers.LegacyRecordPreparser
Description:
Converts an incoming legacy flat file (copybook) into an XML file. For more information, see the iWay Transaction Adapter for CICS User's Guide.
Parameters:
Parameter | Description |
---|---|
Copybook Location * | The full path to the COBOL copybook. |
Input Encoding * | The Internet Assigned Numbers Authority (IANA) character set for the legacy record. You can select a value from the drop-down list or type the name of a code page directly in the field. By default, the Leave option is selected, which uses the default encoding of the listener. |
Full FD? * | If set to true, then the COBOL record headings appear in the output XML. By default, false is selected. |
Multiple Records? * | If set to true, then multiple CommArea records are produced if the input byte array is larger than the copybook size. By default, false is selected. |
Syntax:
com.ibi.preparsers.XDMultiPart
Description:
The Multipart preparser divides multipart documents for later use. This preparser must be last in the chain. When used, the multipart message is divided so that the body of the message is part 0 and subsequent attachments are 1 to n. The multipart object is carried in the XML document (XDDocument) and can be retrieved and interrogated by your own business service to obtain the individual parts for processing. If the body is a MIME type of _/XML, it is parsed and carried as an XML document.
In a use case scenario, an incoming document can consist of an email where specific information from the email message must be extracted, such as the attachment headers and the attachment file name. The Multipart preparser can transform the message into a multipart format that can be used to call functions on the email, such as _attcnt() (attachment count).
Example:
The configuration parameters pane opens.
COND(_atthdr(2,'Content-Id','mydata'),eq, 'mydata1')
content-type: multipart/mixed; boundary="----=_Part_5_23514719.1234266657921" content-length: 571 mime-version: 1.0 message-id: <17237217.1234266657984.JavaMail.ksugauchi@kmaruyama> ------=_Part_5_23514719.1234266657921 Content-Type: application/xml Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=a.xml <a>a</a> ------=_Part_5_23514719.1234266657921 Content-Type: text/document Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=b.xml Content-Id: mydata1 <b>b</b> ------=_Part_5_23514719.1234266657921 Content-Type: text/document Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=c.xml Content-Id: mydata2 <c>c</c> ------=_Part_5_23514719.1234266657921-
When this multipart input document is processed by the channel, an output XML document (a#.txt) is generated with the following contents:
<?xml version="1.0" encoding="ISO-8859-1" ?>
Syntax:
com.ibi.preparsers.XDMultiPartForNHTTP
Description:
The Multipart for nHTTP preparser divides multipart documents into body and attachments. This preparser can also be used with an nHTTP listener. This preparser must be last in the chain. When used, the multipart message is broken up so that the body of the multipart message is part 0 and subsequent attachments are 1 to n.
In a use case scenario, the Multipart for nHTTP preparser is useful when the incoming message is a multipart document and the headers and attachment portions of the document need to be extracted from the document for additional message processing.
Parameters:
Parameter | Description |
---|---|
Payload Header Namespace | A special register namespace into which any headers on the extracted body part will be stored as HDR registers. If not supplied, body part headers will be saved in the default namespace. |
Message Header Namespace | A special register namespace where message headers can be found. If not supplied, HDR registers from the default namespace will be used. |
Keep Message Flat | Determines whether to keep the body of the message as an array of bytes. Select true or false from the drop-down list. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
content-type: multipart/mixed; boundary="----=_Part_5_23514719.1234266657921" content-length: 571 mime-version: 1.0 message-id: <17237217.1234266657984.JavaMail.soumya@ibi> ------=_Part_5_23514719.1234266657921 Content-Type: application/xml Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=a.xml <a>a</a> ------=_Part_5_23514719.1234266657921 Content-Type: text/document Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=b.xml Content-Id: mydata1 <b>b</b> ------=_Part_5_23514719.1234266657921 Content-Type: text/document Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=c.xml Content-Id: mydata2 <c>c</c> ------=_Part_5_23514719.1234266657921-
When this input document is processed by the channel, an output document (outmpart*.xml) is generated with the following contents:
<?xml version="1.0" encoding="ISO-8859-1" ?>
Syntax:
com.ibi.preparsers.PGPDecrypt
Description:
The PGP Decrypt preparser decrypts an incoming message on the channel into the original unencrypted format. For more information on how to configure the PGP Decrypt preparser, see the iWay Service Manager Extensions User's Guide.
Syntax:
com.ibi.preparsers.XDSOAPPreParser
Description:
The SOAP preparser accepts a SOAP message from any JMS listener and removes the SOAP portion from the envelope. The preparser then parses the SOAP body by iterating through all child nodes and constructs an XML document (XDDocument), which is used to pass between components in a process flow. For more information on how to configure the SOAP preparser, see the iWay Service Manager Extensions User's Guide.
Syntax:
com.ibi.preparsers.XDSREGPreparser
Description:
The SREG preparser sets one or more special registers of a given type.
In a use case scenario, the SREG preparser is useful when the incoming message has variables associated with it and if changes need to be made to the special registers set at a global level, application level, or server level.
Parameters:
Parameter | Description |
---|---|
Type of variable | Type of variable (headers appear in emitted documents as header values). Type del to delete the register. Select one of the following options from the drop-down list:
|
Scope of variable | Determines at what level the variable is defined and therefore controls its life span and visibility. Select one of the following options from the drop-down list:
|
Lock Name | Name of a serialization lock for this set of register operations. |
Call at EOS? | In streaming a last call is made after the last document. Determines whether this service should be called. |
Example:
The configuration parameters pane opens.
The name and description pane opens.
<test/>
Syntax:
com.ibi.preparsers.SwiftBPP
Description:
The SWIFTAckPreParser processes transforms MT021 Systems Messages to XML-formatted documents. For more information on how to configure the SWIFTAckPreParser, see the iWay Integration Solution for SWIFT User's Guide.
Syntax:
com.ibi.preparsers.SwiftPreParser
Description:
The SWIFTPreParser converts an incoming SWIFT message to XML format. If you require a SWIFT Validation Report, the SWIFTPreParser must be used. If you do not require a SWIFT Validation Report, the SWIFTPreParser or XDSWIFTPreParser can be used. When the SWIFTPreParser is used, an Ebix must be attached to the iSM channel. For more information on how to configure the SWIFTPreParser, see iWay Integration Solution for SWIFT User's Guide.
Syntax:
com.ibi.preparsers.XDSWIFTSysMsgPreParser
Description:
The XDSWIFTSysMsgPreParser Transforms SWIFT User-to-System and System-to-User FIN Format Messages to XML formatted documents. For more information on how to configure the XDSWIFTSysMsgPreParser, see the iWay Integration Solution for SWIFT User's Guide.
Syntax:
com.ibi.preparsers.XDSWIFTpreParser
Description:
The XDSWIFTPreParser converts an incoming SWIFT message to XML format. Use the XDSWIFTPreParser only if you do not require a SWIFT Validation Report. When the XDSWIFTPreParser is used, an Ebix must be attached to the iSM channel. For more information on how to configure the XDSWIFTPreParser, see the iWay Integration Solution for SWIFT User's Guide.
iWay Software |