Syntax:

com.ibi.agents.XDAccumEOSAgent

iIT Service Object:

accumulation: Accum EOS Agent

Description:

This service accumulates document pieces and emits a full document at End of Stream (EOS).

Parameters:

<Final Root Parameter Value>
   <Accumulated Piece> … </Accumulated Piece>
   <Accumulated Piece> ... </Accumulated Piece>
    …
</Final Root Parameter Value >

Edges:

The following table lists the available line edges for the Accumulate EOS Service (com.ibi.agents.XDAccumEOSAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Example:

The best application of the Accumulate EOS Service would be to merge the documents produced by the splitter for the final output. The architecture of a sample channel would contain an inlet with a File listener and a splitter (for example, XML Splitter preparser). The route would contain a process flow with the Accumulate EOS Service object.

In this example, the following iWay response document is used as the incoming document:

<?xml version="1.0" encoding="UTF-8"?>
<iway>
<response totalrows="3">
<cncresult>
<result format="field">
<resultset rowcount="3">
<colinfo>
<col type="4" length="11" offset="0">Document_Link_ID</col>
<col type="12" length="50" offset="11">Value</col>
</colinfo>
 <row>
   <Document_Link_ID type="4">103</Document_Link_ID>
   <Value type="12">invoice</Value>
 </row>
 <row>
   <Document_Link_ID type="4">103</Document_Link_ID>
   <Value type="12">Milestone</Value>
 </row>
 <row>
   <Document_Link_ID type="4">103</Document_Link_ID>
   <Value type="12">Work Order</Value>
 </row>
</resultset>
</result>
</cncresult>
<timestamp>2007-01-10T17:02:48Z</timestamp>
<execstatus>0</execstatus>
</response>
</iway>

In this incoming document, notice that the <row> element loops three times. Therefore, a splitter can be used on this tag to split the incoming document into three individual documents, where each document corresponds to one loop iteration of the <row> element.

The XML Splitter preparser is configured to split the iWay response document into multiple XML documents, each containing one row, as shown in the following image:

Notice that a counter is being added to each row. This is configured in the event that there is a need to merge the rows again into a single document after performing certain operations.

The Accumulate service can be used to assemble these individual documents into one merged document. In this case, the root element iway would be specified as a value for the Final Root parameter.

The following is the assembled output of the channel:

<?xml version="1.0" encoding="ISO-8859-1" ?>
<iway>
 <eda count="1">
  <response totalrows="3">
   <cncresult>
    <result format="field">
     <resultset rowcount="3">
      <colinfo>
       <col type="4" length="11" offset="0">Document_Link_ID</col>
       <col type="12" length="50" offset="11">Value</col>
      </colinfo>
      <row>
       <Document_Link_ID type="4">103</Document_Link_ID>
        <Value type="12">invoice</Value>
      </row>
     </resultset>
    </result>
   </cncresult>
  </response>
 </eda>
 <eda count="2">
  <response totalrows="3">
   <cncresult>
    <result format="field">
     <resultset rowcount="3">
      <colinfo>
       <col type="4" length="11" offset="0">Document_Link_ID</col>
       <col type="12" length="50" offset="11">Value</col></colinfo>
       <row>
       <Document_Link_ID type="4">103</Document_Link_ID>
       <Value type="12">Milestone</Value>
       </row>
     </resultset>
    </result>
   </cncresult>
  </response>
 </eda>

 <eda count="3">
  <response totalrows="3">
   <cncresult>
    <result format="field">
     <resultset rowcount="3">
      <colinfo>
       <col type="4" length="11" offset="0">Document_Link_ID</col>
       <col type="12" length="50" offset="11">Value</col>
      </colinfo>
      <row>
       <Document_Link_ID type="4">103</Document_Link_ID>
       <Value type="12">Work Order</Value>
      </row>
     </resultset>
    </result>
   </cncresult>
  </response>
 </eda>
</iway>

Note the differences between the incoming and outgoing document. In the outgoing document, the structure is slightly rearranged and a loop counter is represented by the <eda> element with an incrementing count attribute. This counter is used to mark each iteration of the loop.

Syntax:

com.ibi.agents.XDAccumIterAgent

iIT Service Object:

iterator: AccumIterAgent

Description:

Accumulates by gathering during iteration and releasing after iteration.

Parameters:

Parameter	Description
Stage	Gathering adds to the accumulation during the iteration. Releasing emits an accumulated document to the flow.
Correlation Key	Correlates gather and release side. Both must have the same key name. accum

Edges:

The following table lists the available line edges for the Accumulate Iteration Service (com.ibi.agents.XDAccumIterAgent).

Line Edge	Description
OnCompletion	Complete
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse fail_notfound

Syntax:

com.ibi.agents.XDXALogBizErr

iIT Service Object:

operations: Activity Log Business Error Message

Description:

A business error is an error detected by a process relating to the business activity being performed. It is not a hardware or software error. Business errors can be added to the activity log by this agent.

Parameters:

Edges:

The following table lists the available line edges for the Activity Log Business Error Message Service (com.ibi.agentsXDXALogBizErr).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Syntax:

com.ibi.agents.XDXalogControlAgent

iIT Service Object:

iterator: AccumIterAgent

Description:

Control (Start or Stop) the specified activity log Provider(s).

Parameters:

Parameter	Description
Name	The name of a deployed activity log exit to be controlled. This log may be active or inactive.
Action	Actions to take. Start: Start an activity log exit that is in stop state. Stop: Stop an activity log exit that is started.
Wanteos	When using a streaming preparser in a channel, the last call is made AFTER the last document service exit is called. False True

Edges:

The following table lists the available line edges for the Activity Log Business Error Message Service (com.ibi.agentsXDXALogBizErr).

Line Edge	Description
OnCompletion	Complete
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure success fail_parse fail_notfound fail_duplicate fail_operation

Syntax:

com.ibi.agents.XDXALogEvent

iIT Service Object:

operations: Activity Log Entry

Description:

This service is used to record events to the system log during a process flow. It can record security events and arbitrary user event codes. Each message that is logged has a type, code, and optional message.

Parameters:

Available Response Edges for XDXALogEvent

When you connect the XDXALogEvent object to an End object using the OnCustom build relation in a process flow, the available edges are provided in the Line Configuration dialog box.

Edges:

The following table lists the available line edges for the Activity Log Entry Service (com.ibi.agents.XDXALogEvent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_Parse

Syntax:

com.ibi.agents.XDAddAttachmentAgent

iIT Service Object:

attachments: Add Attachment

Description:

This service adds a new attachment with the contents determined by the value of a string expression. The Java Character Set parameter specifies how the Java characters in the string are converted to bytes in the body of the attachment. The attachment headers are specified by the special registers of type HDR in the MIME Header Namespace.

There are also four parameters available to specify the most common MIME headers. When used, these parameters override special registers of the same name. Notice the value of the Content-ID header is taken as is, so the value must contain the surrounding angle brackets. For example, a valid value for Content-ID might be <cid>. This service follows the OnSuccess edge upon successful execution, otherwise it follows OnError.

Parameters:

Edges:

The following table lists the available line edges for the Add Attachment Service (com.ibi.agents.XDAddAttachmentAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Syntax:

com.ibi.agents.XDAddAttachmentFromFileAgent

iIT Service Object:

attachments: Add Attachment From File

Description:

This service adds a new attachment with the contents determined by the contents of a file. This service is convenient to provide binary data without first going through a Java character set encoding. The attachment headers are specified by the special registers of type HDR in the MIME Header Namespace.

There are also four parameters to specify the most common MIME headers. When used, these parameters override special registers of the same name. Notice the value of the Content-ID header is taken as is, so the value must contain the surrounding angle brackets. For example, a valid value for Content-ID might be <cid>. This service follows the OnSuccess edge upon successful execution, otherwise it follows OnError.

Parameters:

Edges:

The following table lists the available line edges for the Add Attachment From File Service (com.ibi.agents.XDAddAttachmentFromFileAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Syntax:

com.ibi.agents.XDAddCorrelEntryAgent

iIT Service Object:

misc: Add Correl Entry Agent

Description:

Uses a correlation management bus to initialize a correlated process. For more information, see the Correlation Facility topic in the iWay Service Manager User's Guide.

Edges:

The following table lists the available line edges for the Add Correl Entry Service (com.ibi.agents.XDAddCorrelEntryAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation fail_duplicate fail_reissue fail_closed fail_notfound

Syntax:

com.ibi.agents.XDAltRouteIP

iIT Service Object:

operations: Alt Route IP

Description:

This service is used to check for a primary host. If that host is not reachable, an alternate host is checked. This is useful for alternate routing.

Parameters:

Edges:

The following table lists the available line edges for the Alt Route IP Service (com.ibi.agents.XDAltRouteIP).

Syntax:

com.ibi.agents.XDAQEmitAgent

iIT Service Object:

misc: AQ Emit Agent

Description:

This service sends a message to an Oracle AQ queue.

Parameters:

Edges:

The following table lists the available line edges for the AQ Emit Service (com.ibi.agents.XDAQEmitAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_connect

The result of the Oracle AQ post appears in the <native> section of the <emitstatus> result. For more information, see the iWay Adapter for OracleAQ User’s Guide.

Syntax:

com.ibi.agents.AS1EmitAgent

iIT Service Object:

misc: AS 1 Emit Agent

Description:

Emits AS1 (email) messages. For more information, see the iWay Service Manager Protocol Guide.

Parameters:

Edges:

The following table lists the available line edges for the AS 1 Emit Service (com.ibi.agents.AS1EmitAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Syntax:

com.ibi.agents.AS2EmitAgent

iIT Service Object:

misc: AS 2 Emit Agent

Description:

General AS2 emitter for use within the service stack. For more information, see the iWay Service Manager Protocol Guide.

Parameters:

Edges:

The following table lists the available line edges for the AS 2 Emit Service (com.ibi.agents.AS2EmitAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Syntax:

com.ibi.agents.XDNAS2EmitAgent

iIT Service Object:

emit: AS2 Nonblocking Emit

http: AS2 Nonblocking Emit

Description:

Emits AS2 messages to a client without interrupting a configured business process. For more information, see the iWay Service Manager Protocol Guide.

Parameters:

Parameter	Description
Configuration Parameters
Destination	URL that is used to post this information.
HTTP Client Provider	HTTP client provider that is used to manage connections for this emitter.
AS2-From	A textual value identifying the sender of data exchange.
AS2-To	A textual value identifying the receiver of data exchange.
Subject	Sets the Subject header.
Request Receipt	Tells the emitter to send a request for receipt in the form of a Message Disposition Notification (MDN).
Asynchronous Receipt URL	If an asynchronous receipt should be requested, specify the URL to which the receipt should be sent. Supported values are in the form: mailto:user@host. For asynchronous receipt by email. http://host[:port]/. For asynchronous receipt by HTTP. https://host[:port]/. For asynchronous receipt by HTTPS.
Receipt Destination	Directory into which synchronous MDNs are stored. Specific file name is optional. Use * in file name to add a timestamp and use # to add a sequential counter.
Content-Type	Specifies the content-type of data to be sent. Select from the drop-down list or provide your own.
Message ID	Set this to control the emitted message ID. Usually this is left blank to let the system generate a unique ID meeting the requirements of RFC 822. Use this only to override the default. This is not recommended.
Content Disposition	File name to put in the Content-Disposition header value.
User ID	User ID for Basic Authentication challenges.
Password	Password for Basic Authentication challenges.
Domain	Domain for NTLM authentication challenges. To use NTLM, you must enable connection persistence.
Request Header Namespace	Special register namespace from which HTTP headers for the outgoing request will be taken. Default Namespace. To send HDR type registers. Supply a namespace prefix here to indicate which headers to send. None. Means that no special registers will be sent as HTTP headers.
Request Main Part Header Namespace	Special register namespace from which MIME headers for the outgoing request will be taken. Provide a prefix to control the request Main BodyPart headers in the presence of attachments. Selecting none means that no special registers will be sent as MIME headers.
Response Header Namespace	Special register namespace into which HTTP headers for the incoming response will be saved. Default Namespace. To create special registers with no namespace. Supply a namespace prefix here to indicate header namespace.
MDN Header Namespace	Special register namespace into which MIME headers of the multipart/report entity will be saved. This namespace is ignored if the MDN is unsigned since all headers will be in the Response Header Namespace.
MDN Field Namespace	Special register namespace into which MDN fields will be saved.
Excluded Headers	A comma delimited list (case-insensitive) of headers that should not be sent with the request, even if they are found in the request header namespace.
Ask for Compressed Response	If set, requests will set the Accept-Encoding header to indicate that the client can accept a compressed response, as described in RFC-2616. If the response has a compressed content encoding, the client will automatically inflate.
Compress Request	If set, the HTTP request entity will be compressed using the selected encoding and the Content-Encoding header will be set accordingly.
Replace Connection?	If set to false, the connection will not be returned to the connection pool immediately. The identifier of the connection will be stored in the HTTP client-key special register and the connection can be handled by the HTTP Client Manager agent.
Maximum HTTP Client Manager Delay	Maximum time the HTTP Client Manager can take to address a particular connection before it is automatically aborted. The format is [xxh][xxm]xx[s]. The default is 60 seconds.
Maximum Request Size	Maximum size, after compression, of a request entity that can be sent with this emitter. 0 means no maximum and blank will default to 256KB.
Maximum Response Size	Maximum size of a response entity that can be received by this emitter. 0 means no maximum and blank will default to 256KB.
Try Expect/Continue Handshake?	If checked, client will send the HTTP Expect: 100-continue header and await the HTTP 100 response before sending the request body.
S/MIME
Packaging	Tells the emitter how the document should be packaged for transmission. Select from the drop-down list: Encrypted Signed Signed and Encrypted Un-encrypted
Compression	Determines when message compression should be applied. Select from the drop-down list: Compress After Signature Compress Before Signature No Compression
S/MIME Keystore Provider	Provider for the Keystore used to sign and encrypt messages.
S/MIME Truststore Provider	Provider for the Keystore containing the S/MIME Certificate Authorities.
S/MIME Certificate Store Providers	Comma-separated list of Keystore, Directory CertStore, or LDAP providers for the certificate stores used to complete signer certificate chains when the signed message contains fewer certificates than needed.
S/MIME JCE Cryptography Provider	JCE Provider for S/MIME Cryptography services.
S/MIME Verification JCE Crypto Provider	JCE Provider for S/MIME verification cryptography services. Normally left blank. Defaults to S/MIME JCE Provider.
S/MIME PKIX JCE Provider	JCE Provider for S/MIME PKIX services. If left blank, the default JCE provider for PKIX will be used.
Recipient Public Key Alias	The alias for the recipient public key entry used for encryption.
Signature Key Alias	The alias for the private key entry used for signing.
Signature Key password	Password to access the signature private key. If left blank, the password used to access the Keystore will be used.
Digest Algorithm	Algorithm to be used for signing.
Encryption Algorithm	Algorithm to be used for encrypting.
Include Certificate Chain	Determines how much of the signer certificate chain is included in the message. Select from the drop-down list: Complete Certificate Chain No Certificate Signer Certificate only
Enforce KeyUsage Extension	If set to on, verify certificates used for signing allow the digital Signature KeyUsage extension, and certificates used for encryption allow the key Encipherment KeyUsage extension.
Enable Certificate Revocation	If set to true, use the CRLs from the CertStores to check whether the signer's certificate has been revoked.
Unrecognized Certs Location	Directory to store unrecognized certificates found in S/MIME messages.
IP Properties
Persistence	If checked, ask the server to maintain the connection.
Response Timeout value in seconds	Seconds to wait for a response before signaling an error.
Agent Specific parameters
Return	Return from this agent. Select one of the following options from the drop-down list: input status response
Preemitter	Determines whether any preemitter should be avoided. If set to true, preemitters will not run.
Response Wrapper Tag	The tag name with which to wrap the response if the response is non-XML and must be XML.
Response Base64 Encoded	If set to true, Response will be Base64 encoded.

Edges:

The following table lists the available line edges for the AS2 Nonblocking Emit Service (com.ibi.agents.XDNAS2EmitAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_connect fail_info fail_redirection fail_client fail_server fail_operation fail_parse fail_request_too_large fail_response_too_large fail_unsigned

Syntax:

com.ibi.agents.XDMDNSendNowAgent

iIT Service Object:

misc: AS2 Nonblocking Send MDN

Description:

The AS 2 nonblocking send MDN service is a new service that is available in the NAS2 adapter configuration. For more information, see the iWay Service Manager Protocol Guide.

Edges:

The following table lists the available line edges for the AS 2 Nonblocking Send MDN Service (com.ibi.agents.XDMDNSendNowAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation

Syntax:

com.ibi.agents.XDIterAttachments

iIT Service Object:

iterator: Attach Iterator

Description:

Handle each attachment of the current document per iterative.

Parameters:

Parameter	Description
Handle Option	How to handle identified attachments delete: removes each attachment from current document after processing. replace: replaces the original attachment with a the modified document. leave: leaves original attachments unchanged.
Start Index	Index of the first attachment to process in the mail object. The first attachment to the main document has an index of 0 (zero).
Header Namespace	The special register namespace where MIME headers for the current attachment will be stored. If replace handling option is selected, registers in the namespace will be added to the replaced attachment.
Main Body Part Header Namespace	If the current attachment is itself a multipart, then this is the special register namespace where the MIME headers for the main body part will be stored.
Keep Document Flat	Keeps the body of the document as an array of bytes. True False

Edges:

The following table lists the available line edges for the Attachment Iterator Service (com.ibi.agents.XDIterAttachments).

Line Edge	Description
OnCompletion	Complete
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse fail_operation fail_notfound

Syntax:

com.ibi.agents.XDAttachOps

iIT Service Object:

attachments: Attachment Operations

operations: Attachment Operations

Description:

This service performs operations on document attachments.

Parameters:

Edges:

The following table lists the available line edges for the Attachment Operations Service (com.ibi.agents.XDAttachOps).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation fail_parse fail_notfound

Syntax:

com.ibi.agents.XDAttachmentToDocAgent

iIT Service Object:

attachments: Attachment to Document

Description:

This service finds an attachment and makes it the body of the document. The attachment can be selected by index or by Content-ID. If the Attachment Number is specified, it takes precedence over the Content- ID. The attachment index is base 0. If present, the Content- ID must NOT contain the surrounding angle brackets.

For example, the value cid for the Content-ID parameter will match an attachment with a Content-ID header equal to <cid>. The Header Namespace is the special register namespace where MIME headers for the selected attachment will be stored. The attachment will be stored as bytes if the Keep Document Flat parameter is enabled. Otherwise, the attachment will be parsed as XML. If the attachment is itself a Multipart, then the document will contain the parse of the Main Body Part and the other parts will appear as document attachments.

The MIME headers of the Main Body Part will be saved as registers in the Main Body Part Header Namespace. This is needed to keep them distinct from the Multipart headers. The Delete Attachment parameter determines what to do with the selected attachment when it is not a Multipart: the attachment can be preserved or deleted. This service follows OnSuccess upon successful execution, otherwise, it follows fail_notfound if the attachment cannot be found, or it follows fail_operation if there is another error.

Parameters:

Edges:

The following table lists the available line edges for the Attachment to Document Service (com.ibi.agents.XDAttachmentToDocAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation fail_parse fail_notfound

Syntax:

com.ibi.agents.XDAttachmentToDocAgent

iIT Service Object:

objectgroup: object

Description:

Accumulates by gathering during iteration and releasing after iteration.

Parameters:

Edges:

The following table lists the available line edges for the Attachment to Document Service (com.ibi.agents.XDAttachmentToDocAgent).

Line Edge	Description
OnCompletion	Complete
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation fail_parse fail_notfound

Syntax:

com.ibi.agents.XDPrincipalAgent

iIT Service Object:

operations: Security: Authenticate/Impersonate

security: Security: Authenticate/Impersonate

Description:

This service allows a process to authenticate and/or impersonate a user based on credentials in a message or message context.

For more information about the Authenticate/Impersonate service, see the iWay Service Manager Security Guide.

Edges:

The following table lists the available line edges for the Authenticate/Impersonate Service (com.ibi.agents.XDPrincipalAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_security fail_parse

Syntax:

com.ibi.agents.BAMReceiver

iIT Service Object:

objectgroup: BAM Receiver

Description:

This is the BAM Receiver.

Parameters:

Edges:

The following table lists the available line edges for the BAM Receiver Service (com.ibi.agents.BAMReceiver).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure

Syntax:

com.ibi.agents.XDBlankWalk

iIT Service Object:

sreg: Blank [whitespace] elimination

transform: Blank [whitespace] elimination

Description:

The XML standard calls for preserving blanks in element values. As a compliant parser, the iWay Service Manager preserves these spaces as per the standard. In some cases, however, users add superfluous spaces to document element values. This often arises when an XML document is formatted to resemble a printed document and is then passed into the system.

The Blank Elimination service trims these extraneous blank spaces to make future XPATHs or analysis easier.

Parameters:

Edges:

The following table lists the available line edges for the Blank Elimination Service (com.ibi.agents.XDBlankWalk).

Example:

For example, given the following input XML document:

<root>
   <sub>   <sub2>   hello   </sub2>
   </sub>
   <sub3>![CDATA[     ]]</sub3>
</root>

When the Method parameter is set to All, the following result is generated:

<root><sub><sub2>hello</sub2></sub><sub3>![CDATA[     ]]</sub3></root>

The value of the <sub2> element was trimmed and the whitespace content of the <root> and <sub> elements was eliminated. Notice, however, that the whitespace inside the CDATA node was ignored.

When the Method parameter is set to Empty, the following result is generated:

<root><sub><sub2>   hello   </sub2></sub><sub3>![CDATA[     ]]</sub3></root>

The document is treated just as above, except that in this case, the value of the <sub2> element is not trimmed.

Syntax:

com.ibi.agents.XDBase64Agent

iIT Service Object:

format: Base64 Operation

Description:

This service encodes or decodes a portion of a document using Base64 encoding. Base64 is a specific content transfer encoding scheme that translates binary data into a base 64 representation. Base 64 is set of 64 characters that is part of the subset common to most encodings, and also printable. It is possible to store non-unicode fields within an internal document even though under XML rules such a document cannot be parsed. The Base64 service enables these fields, or the entire incoming document, to be replaced with bytes, and these bytes to be translated into a base 64 representation.

Parameters:

Edges:

The following table lists the available line edges for the Base64 Operation Service (com.ibi.agents.XDBase64Agent).

Example:

In a use case scenario, the Base64 service can be used to handle binary data from a picture or image. For example, you can use it to decode a picture that is temporarily stored in base64 format within the picture tag of an incoming XML document. The data can be placed in a file and later saved with the appropriate extension to be viewed by a photo editor.

The following image is an example of configuration settings for a Base64 service object in iIT Designer:

Refer to the Pictures sample that is packaged with iWay Service Manager for the sample input file. For example, the input document that is used by the Samples.Pictures.CreatePictureInsertRequest.1 transformation.

Syntax:

com.ibi.agents.CCharFilter

iIT Service Object:

misc: C Char Filter

Description:

Some input documents contain control characters such as tabs or bells. This service replaces or removes such characters.

Parameters:

Edges:

The following table lists the available line edges for the C Char Filter Service (com.ibi.agents.CCharFilter).

Example:

If you need to replace a new line character in an incoming document with a period (.), this service needs to be configured with default parameter values, except for the Replace With parameter value, which must be set to period (.). The result of passing the incoming document with a new line character inside the <Test> tags is:

<?xml version="1.0" encoding="UTF-8" ?>
<Test>.</Test>

Syntax:

com.ibi.agents.XDCancelAgent

iIT Service Object:

operations: Cancel a Service

Description:

The execution of one or more services on other execution edges of a process flow can be cancelled by using the Cancel Service (com.ibi.agents.XDCancelAgent). This service accepts the name of one or more target services. Upon execution, a cancellation request is sent to the named service(s).

The cancellation capability facilitates the construction of caches, in which a slower operation (such as accessing a remote database) is run in parallel with a faster, local cache search. If the cache finds the required entry in the local database, then it can cancel the slower operation.

A cancel operation can only be directed to a service node (agent) that supports cancellation. In addition, that service must be able to actually cancel. For example, the SQL Object used in process flows can issue a cancel operation, but the effectiveness of the cancellation will depend upon the underlying database interfaces.

Parameters:

Parameter

Description

Service to cancel *

Upon execution, the identified service(s) in this field will be sent a cancellation request. The service(s) specified here should offer an OnCancel/cancellation edge to terminate the execution thread. You can specify an individual service name, a comma-delimited list of service names, or a space-delimited list of service names. Service names with spaces, commas, or other special characters must be enclosed in quotes.

Edges:

The following table lists the available line edges for the Cancel Service (com.ibi.agents.XDCancelAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse

Example:

In the following cache example, the CancelReal node represents the Cancel Service (com.ibi.agents.XDCancelAgent).

In this process flow, the CancelReal node is configured to cancel the AccessReal database access, which is anticipated to be slower than the AccessCache operation.

Although the local and remote sides of this process flow each go to the Junction node and thus to the End node, only one side will reach it.

Caches are very timing dependent. As a result, this example is simplified and is not intended to show a fully working cache.

Syntax:

com.ibi.agents.XDCatchAgent

iIT Service Object:

operations: Catch errors in flows

Description:

Error handling in iWay Service Manager (iSM) process flows can be accomplished in a number of different ways. Supported method and techniques include:

• Explicitly checking for an error, post-service execution, by conditioning the edge with onError or onFailure.
• Including an outlet conditioned with _iserror().
• Including a Catch service at the beginning of the channel. This channel has two edges on the output side that are used for processing. The first is the onCompletion edge. The second is the onCustom edge, with the onError and onFailure cases selected.

The concept of the Catch service is similar to a try-catch block in other programming languages.

In other programming languages, a block of code is enclosed between the braces of a try statement. Following the try block is a catch block of code that is enclosed in braces. The code in the catch block has statements that handle any errors that might occur in the try block.

When the thread of execution starts, each line in the try block of code is executed. If each statement is successful, execution continues at the statement following the closing brace of the catch block (assuming that there is not a finally block). If an error occurs within the try block, the thread of execution jumps to the code inside the catch block.

In a process flow, you can add a Catch node in front of the services in which an error might occur. There are five edges off this service:

• onCompletion
• onCustom
• onSuccess
• onError
• onFailure

The completion edge is the thread of execution in which everything works in a perfect scenario. All the edges after the service connected by the onCompletion edge are then connected to the onSuccess edge.

The onCustom edge has three selected cases (onError, onFailure, and error_retry). Any errors or failures that occur within the path of the process flow are directed down the onError and onFailure edge. The logic in this branch contains any services necessary to handle errors. The error_retry edge is followed when there is a retry exception. For example, when a SQL Object contains an invalid URL in the process flow, the onCustom/error_retry edge will be followed.

Think of the onCompletion path as the try block and the onCustom edge as the catch block.

You can add multiple Catch nodes in a process flow. The error branch is taken off the closest Catch node previous to where the error occurred. In this manner, you can add multiple error conditions for a given process flow if required.

The catch is hierarchical and each catch is considered nested in the prior Catch node. When a Catch node is triggered, the Special Register (SREG) iway.catchname is set to the name of the Catch node that first catches the error. The register is not replaced as succeeding Catch nodes see the error. This allows higher scopes to ascertain the scope under which the original error is caught. For example, if Task3 fails and the error is caught by CatchScope3, the register will be set to CatchScope3 even though the error may cascade through higher scopes.

Parameters:

Parameter	Description
Maximum Entries	The maximum number of times a CATCH will be effected per forward entry.

Example 1

In this example, consider a process flow in where three tasks are performed serially (called Task1, Task2, and Task3). The process flow performs three tasks, as shown in the following image.

There is a requirement to handle errors in each task separately. So in our updated process flow, a Catch node precedes each Task node to handle errors in that task.

In this example, assume Report1 to Report3 are each an SQL object recording failures. If Task3 (on the main line of the process flow) fails, then the failure is caught by CatchScope3. Report3 records the failure and control passes to Fail3. Fail3 is a Fail service, which has a Bypass Catch Processing parameter set to true. For more information on the Fail service, see Fail Service (com.ibi.agents.XDFailAgent).

However, if Report3 fails, then the failure will be caught by CatchScope2. The Catch node for scope three does not catch the Report3 failure as it has already caught a failure. The scope in this example tests to determine whether the failure was in its scope, in which case Report2 will record the failure within the scope, or in a lower scope. It does this by the NotMe2 test, which evaluates the scope. This is a test node, which is set to the following parameter values:

This causes the extra report to be bypassed. In this case, or example uses a Trace service (Trace1, Trace2) to report the error in the lower scope to a simple trace message. Following the trace message reporting a failure in a lower scope, the process flow uses a Fail service to issue the fail that did not get issued in the lower scope. This maintains the statistics of the channel.

In the multiple Catch node use case, setting the Bypass Catch Processing parameter of the Fail node to true will cause the failure request to bypass upper-level Catch nodes, avoiding the need for scope testing (such as with the example in the My Scope tests in upper scopes).

Example 2

In this example, a file is put into a directory after its creation from a previous channel. The sample process flow is responsible for transmitting the file to the customer FTP site.

Since this is an FTP site, it is subject to network and site availability and other possible outside issues. An error handling strategy is required so that none of the documents being processed are lost because of an outside issue.

In process flow, the Catch node immediately follows the Start block. An onCompletion edge connects the Catch Errors block to the FTP Write block. The FTP Write block is an FTP emitter that is set up to write the file to an FTP site. The service directly following the XDCatchAgent (Catch Errors) must have an onCompletion edge for this to work correctly.

Following the FTP Write block is the End block. The edge connecting these two services is an onSuccess edge. If a different edge were used and an error occurred, the error edge off of Catch Errors may not be executed.

The onCustom edge of Catch Errors has the onError and onFailure cases selected for the properties. This edge leads to a file write service, Write Error, that puts the file into a hold directory for later reprocessing. Following Write Error, there is an End with a Terminate since no further processing is required at this point. In a real world scenario, a requirement might be that an email is sent if the site is down.

When the target FTP site is up and available, the files are written to the FTP site. If the FTP site is down or you cannot connect to it, the FTP write service will generate an error. This error causes the next execution point to be the File Write to save the file for further processing.

Syntax:

com.ibi.agents.XDChanInfoAgent

iIT Service Object:

operations: Server Statistics

Description:

This service returns an XML document that contains the current status information for the system. The service is also available for use in process flows. Each channel (represented by a master tag) is included in the XML output, along with statistics on its current state.

Properties:

Edges:

The following table lists the available line edges for the Channel Information Service (com.ibi.agents.XDChanInfoAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure

Example:

The following is a sample of an XML document that is returned by the service:

<info>
 <channels>
  <master name="internal" state=" active " type="Internal" completed="0"
failed="0" active="0" available="1">
   <user mean="0.0" variance="0.0" ehrlang="1.0"/>
    <cpu mean="0.0" variance="0.0" ehrlang="1.0"/>
     <threads group="internal">
      <thread name="W.internal.1"/>
     </threads>
  </master>
  <master name="file1" state=" active " type="FILE" completed="0"
failed="0" active="0" available="4">
   <user mean="0.0" variance="0.0" ehrlang="1.0"/>
    <cpu mean="0.0" variance="0.0" ehrlang="1.0"/>
     <threads group="file1">
      <thread name="W.file1.1"/>
      <thread name="W.file1.2"/>
      <thread name="W.file1.3"/>
      <thread name="W.file1.4"/>
     </threads>
  </master>
 </channels>
 <internalqs>
  <queue name="internal1" size="0"/>
 </internalqs>
</info>

Syntax:

com.ibi.agents.CheckSchema

Note: The CheckSchema service has been deprecated. Use the XDCheckSchema service instead.

Description:

Evaluates the input document against a specified schema. Optionally, this service can route the document to the fail edge or can simply set the appropriate document state that can later be tested with the following iWay Functional Language (iFL) statement:

_hasschemaerr()

Parameters:

Edges:

The edges returned are listed in the following table.

Example:

You can examine the process flow that uses the pictures.SqlInsertPicture sample schemas on the route. Specify the schema using iIT Designer, as shown in the following image.

Your process flow will finish at the End1 object (success result) if you run the document that corresponds to the schema.

<?xml version="1.0" encoding="UTF-16" ?>
<AdapterParams location="RDBMS/Schemas/PUBLIC/Tables/PICTURES/INSERT">
<ID />
<DESC />
<IMG>//4wIFAATgBHAA0ACgAaAA0ACgANAAoASQBIAEQAUgANAAoADAAMABEADgARABUAGQA
NAAoADAASAA0ACgAUABcAFQAZABsAGQAkAB0AIwArACgAGwAZADQAHQAWACIAHAAqACcAIgA
eADoAJAAYACcA eAGPACwAywAsAEEALAD7AF8AWQD/AGUA0wDlABsAeADUAA==</IMG>
</AdapterParams>

If you run the process flow with the document that fails the schema validation, such as <Test></Test>, the process flow will finish at the End object (fail result).

The content of the message does not change after using this service.

Syntax:

com.ibi.agents.XDCheckSchema

iIT Service Object:

misc: Check Document Against External Schema

Description:

The XDCheckSchema service evaluates an input document against a specified schema. In scenarios where a schema represents an agreement between the sender of a document and the receiver (for example, iWay Service Manager), schema checking is important for debugging purposes. It has lesser importance during actual production. However, this is ultimately an application design decision.

Note: Checking a schema can consume system resources and processing time. As a result, it is not recommended during operation in production environments.

Parameters:

Edges:

The following table lists and describes the edges that are returned by the XDCheckSchema service.

Example:

In this example, an absolute path to a schema is specified for the Schema File property.

Instead of providing an absolute path to the schema, you can also specify the location of a .zip archive file where the schema is packaged. In this case, you must also provide a value for the Schema Name property, which will direct this service to the root schema in the .zip archive file. For example:

• Schema File. c:\temp\abc.zip
• Schema Name. sample1.xsd
• Strictness. strict

You can also select route or start node from the Schema File drop-down list. If route is selected, then the schema is retrieved from the route that is currently managing the channel. If start node is selected, then the schema is retrieved from the process flow Start object, as shown in the following image.

When the process flow is executed, the input file is validated against the specified schema and an appropriate output document is generated.

Syntax:

com.ibi.agents.XDCommittAgent

iIT Service Object:

operations: Commit/Rollback during flow

Description:

Like the XDCatchAgent, this service serves as a placeholder for a process flow function. Unless the Supports Local Transaction attribute is set in the listener of the channel, this node is a functional NOP.

When operating in Local Transaction mode, database and other operations begun by nodes within the flow are committed or rolled back based on the final status of the flow itself. The commit or rollback is performed within the constraints of the local transaction capability of the server.

The XDCommitAgent, when encountered in a flow, causes a commit or a rollback operation to take place immediately. This allows two or more transactions in a single flow. Use of this capability is dependent on application design.

The agent is configured for commit or rollback. This is not possible using iFL.

When encountered, the commit handler awaits completion of all other threads in the flow, if any. It then calls the commit manager to commit or roll back work established to date. This in turn causes all open connections to be released. The specific action on a commit or roll back is dependent on the resource being affected. Note that mis-specification of set or synch waits can cause the flow to enter a deadlock condition.

Once committed, the data cannot be rolled back, regardless of the manner in which the flow actually ends. The node is a punctuation within the flow, and users should consider actions subsequent to the commit or rollback as a separate flow.

A common use of such a capability is with a Catch node. If catch traps an error, the error edge might issue a roll back and then proceed to take other action to record or recover from the error.

Edges:

The following table lists the available line edges for the Channel Information Service (com.ibi.agents.XDChanInfoAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operations

Syntax:

com.ibi.agents.XDConstantAgent

iIT Service Object:

misc: Constant Agent

Description:

Replaces the input document with a constant document. Because all parameters are evaluated with the iWay Functional Language (iFL), this service is frequently used to modify the input or load a file from a disk, and so on.

Parameters:

Edges:

The edges returned are listed in the following table.

Example:

If you run this service using any input document, the same constant document output is returned. For example, if you are using <a>aaa</a> as a constant, the following is the result:

<?xml version="1.0" encoding="UTF-8" ?>
<a>aaa</a>

Syntax:

com.ibi.agents.XDXalogControlAgent

iIT Service Object:

xalog: Activity Log Control

contol: Activity Log Control

Description:

Activity log exits accept messages pertaining to activities in the server, and report these activities to some external media. A common exit is the BAMActivityProvider. Other exits relate to SNMP, time tracking, and so on. The exits are defined and deployed for the configuration, and may initially be defined as being in an active or inactive state. Active state refers, as in all components, to whether the exit is initialized and started automatically when the server is initialized.

These exits can be configured for the server in the Activity Facility section of the iSM Administration Console.

This service can be used in a process flow to start or stop the named activity log exit. You might use this, for example, in a BAM error recovery flow to restart the exit that has been stopped due to a database error.

Parameters:

Edges:

The edges returned by the Control Activity Log Exit service (com.ibi.agents.XDXalogControlAgent) are listed and described in the following table.

Syntax:

com.ibi.agents.XDControlAgent

iIT Service Object:

control: Controls Listeners

Description:

The Controls Listeners service enables or disables one or more listeners or channels. This functionality enables logical control of the server configuration from within a process flow. The following are the supported control operations/actions:

• start
• pause
• pulse
• stop

Using the Controls Listeners service, the activity on one listener can control another. For example, the detection of a message in an MQ Series queue can trigger an RDBMS listener to begin working with a relational table.

Parameters:

Edges:

The following table lists the available line edges for the Controls Listeners service (com.ibi.agents.XDControlAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure

Example:

You can use the Controls Listeners service to stop a channel that is currently running in iWay Service Manager (iSM). In a process flow, configure a Service object using the Controls Listeners service (com.ibi.agents.XDControlAgent). Click the Properties tab. For the Listener(s) parameter, specify the name of the channel that you want to stop (for example, default).

Invoke the channel that contains the Controls Listeners service process flow in the route with a valid XML document. The stop command for the default channel will be issued. If the default channel is currently running, then it will be stopped.

You can verify this action by examining the status change for the default channel in the Channel Management pane after successfully passing the XML document through the Controls Listeners service channel.

Notice that the default channel is now stopped.

Syntax:

com.ibi.agents.XDCorrelInquiryAgent

iIT Service Object:

misc: Correl Inquiry Agent

Description:

Returns an XML report on the specified correlation ID. For more information, see the Correlation Facility topic in the iWay Service Manager User's Guide.

Parameters:

Edges:

The following table lists the available line edges for the Correl Inquiry Service (com.ibi.agents.XDCorrelInquiryAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure open closed
notfound	fail_operation

Syntax:

com.ibi.agents.XDCorrelInquiryByStateAgent

iIT Service Object:

misc: Correl Inquiry By State Agent

Description:

Returns a document listing all correlation IDs in the requested state. For more information, see the Correlation Facility topic in the iWay Service Manager User's Guide.

Parameters:

Edges:

The following table lists the available line edges for the Correl Inquiry By State Service (com.ibi.agents.XDCorrelInquiryByStateAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation

Syntax:

com.ibi.agents.XDCorrelSetInquiryAgent

iIT Service Object:

misc: Correll Set Inquiry Agent

Description:

Returns a document describing the status of the requested correlation set ID. For more information, see the Correlation Facility topic in the iWay Service Manager User's Guide.

Parameters:

Edges:

The following table lists the available line edges for the Correl Set Inquiry Service (com.ibi.agents.XDCorrelSetInquiryAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure open closed notfound fail_operation

Syntax:

com.ibi.agents.XDCorsAgent

iIT Service Object:

http: Cross-Origin Resource Sharing

Description:

This service implements the server-side processing of Cross-Origin Resource Sharing (CORS) as described in http://www.w3.org/TR/cors/.

Normally, browsers forbid cross-origin requests for security reasons. CORS specifies a mechanism that allows browsers to make cross-origin requests to resources that opt in to provide access. CORS defines a set of HTTP headers and the rules to process them. Most common browsers implement CORS natively. It is expected that the user agent making the request will be a browser. The CORS service implements the server-side rules to respond to CORS requests received by an nHTTP listener.

If the request is simple (such as GET, HEAD, or POST), then the user agent (for example, the browser) can make the request directly. The user agent adds the Origin header to indicate which site is asking for this resource. The syntax of an origin is:

scheme "://" host [ ":" port ]

The same syntax is used to configure the allowed origins in the service.

If the request is not simple, then the user agent must send a pre-flight request before the actual request to authorize it. The pre-flight request is an OPTIONS request for the same URL. The Access-Control-Request-Method header indicates the method of the actual request (for example, PUT). The optional Access-Control-Request-Headers header indicates which headers will be used in the actual request. Depending on the response of the pre-flight request, the user agent can abort or make the actual request following the same rules as a simple request.

The CORS service analyzes the request, and depending on its configuration, will report one of the following results:

• The request is allowed (allowed).
• The request is not allowed (notallowed).
• The request is not CORS compliant (notcompliant).

In accordance with the specification, the CORS service adds the CORS response headers only if the request is allowed. The new headers appear as Special Registers (SREGs) in the Response Header Namespace.

The CORS service sets the output document of an OPTIONS request to a zero-length byte array. This will return an empty body with Content-Length equal to 0. This is the most appropriate result, but an application can modify the output document afterwards if necessary. For other requests, the CORS service returns the input document as the output document. Unlike the headers, the output document will be the same irrespective of the actual outcome (allowed, notallowed, or notcompliant).

The nHTTP listener must be configured carefully to make CORS processing possible. The OPTIONS Handling property must be set to event. This instructs the listener to pass the request to the channel instead of responding directly. The Request Header Namespace and the Response Header Namespace must not be none, and they must be different from each other. This makes the request headers available to the CORS service, and allows the response headers be sent with the response. Of course, the Excluded Headers property should not list the CORS headers. The HTTP Response Code must be 200 for a CORS pre-flight response. The Authentication Scheme and the Authentication Realm properties should be considered carefully. CORS is a mechanism used to relax security. It does not replace the need for user credentials to protect sensitive data.

Parameters:

The following table describes the parameters for the Cross-Origin Resource Sharing Service.

Parameter	Description
Allowed Origins	List of origins that are allowed access to the resource. Leave empty or enter * to allow all origins. The syntax of an origin is: scheme "://" host [ ":" port ] This property is used to validate the Origin header in the request and influences the value of the Access-Control-Allow-Origin header in the response. The return value of the Access-Control-Allow-Origin header will be * if the Allowed Origins is * and Supports Credentials is false.
Allowed Methods	Comma-separated list of HTTP methods that are supported by the resource. Leave empty to allow all methods. This is used to validate the Access-Control-Request-Method header in the pre-flight request and to initialize the Access-Control-Allow-Methods header in the pre-flight response.
Supported Headers	Comma-separated list of HTTP header field names that are supported by the resource. Leave empty to claim support for all headers. This is used to validate the Access-Control-Request-Headers header in the pre-flight request and to initialize the Access-Control-Allow-Headers header in the pre-flight response.
Exposed Headers	Comma-separated list of HTTP header field names of headers (other than the simple response headers) that the resource might use and can be exposed. This is used to initialize the Access-Control-Expose-Headers header in the response of the actual request.
Supports Credentials	Indicates whether the resource supports user credentials in the request. This is used to initialize the Access-Control-Allow-Credentials header in the response. Notice the return value of the Access-Control-Allow-Origin header will never be * for a resource that supports credentials.
Max Age	Specifies the amount of seconds the user agent (for example, the browser) is allowed to cache the result of the pre-flight request. The value 0 means unbounded. This is used to initialize the Access-Control-Max-Age header in the response of the pre-flight request.

Edges:

The following table lists the available line edges for the Cross-Origin Resource Sharing Service (com.ibi.agents.XDCorsAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success: The message was successfully analyzed. The cors Special Register contains the result.
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation: the service is not executing a request received by an nHTTP listener. open closed notfound

Special Registers:

The following table describes the Special Register (SREG) that is assigned upon a successful execution.

Special Register	Description
cors	The outcome of analyzing the request. This will be one of the following values: allowed notallowed notcompliant Note: These values are lowercase and do not contain any spaces.

GET /app/page1 HTTP/1.1
Host: example.com

GET /app/page1 HTTP/1.1
Host: example.com
Origin: http://host.com

GET /app/page1 HTTP/1.1
Host: example.com
Origin: http://host1.com

Access-Control-Allow-Origin: http://host1.com
Access-Control-Expose-Headers: RespHdr1,RespHdr2
Access-Control-Allow-Credentials: true

OPTIONS /app/page1 HTTP/1.1
Host: example.com
Origin: http://host1.com

OPTIONS /app/page1 HTTP/1.1
Host: example.com
Origin: http://host1.com
Access-Control-Request-Method: HEAD

OPTIONS /app/page1 HTTP/1.1
Host: example.com
Origin: http://host1.com
Access-Control-Request-Method: GET
Access-Control-Request-Headers: ReqHdr1,ReqHdr2

Access-Control-Allow-Origin: http://host1.com
Access-Control-Allow-Methods: GET,POST
Access-Control-Allow-Headers: ReqHdr1,ReqHdr2,ReqHdr3
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 30

Syntax:

com.ibi.agents.XDDQAgent

iIT Service Object:

DQS: Data Quality Service Agent (non-pooling, deprecated)

Description:

This service marshals data and processes data using an iWay Data Quality Provider.

Note: This service is deprecated. The Data Quality Center Service (Document-Driven, Pooling), com.ibi.agents.XDDQAgent2, should be used instead.

Parameters:

Syntax:

com.ibi.agents.XDDQAgent2

iIT Service Object:

DQS: Data Quality Service Agent - Document Driven (pooling)

Description:

This service marshals data from an input document and processes data using an iWay Data Quality Runtime Provider.

Parameters:

Edges:

The following table lists the available line edges for the Data Quality Center Service (Document-Driven, Pooling) (com.ibi.agents.XDDQAgent2).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_partner fail_parse fail_notfound

Syntax:

com.ibi.agents.XDDQAgent2UserParm

iIT Service Object:

DQS: Data Quality Service Agent - User Parm Driven (pooling)

Description:

This service executes an iWay DQC plan and passes user parameters as input data. The plan is dynamic and called by name.

Parameters:

Edges:

The following table lists the available line edges for the Data Quality Center Service (User Parameter-Driven, Pooling) (com.ibi.agents.XDDQAgent2UserParm).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_partner fail_parse fail_notfound

Syntax:

com.ibi.agents.XDDeflateAgent

iIT Service Object:

exit_preemit: Deflate Agent

misc: Deflate Agent

Description:

This service is used to compress the document for transmission or storage. The document is flattened to a byte stream, and compression algorithms are applied. The output of this service is a flat document.

Parameters:

Edges:

The edges returned are listed in the following table.

Syntax:

com.ibi.agents.XDDeidentifyAgent

iIT Service Object:

transform: De-identify an XML Document

Description:

The Deidentification service provides algorithms that can be used to implement the de-identification of protected health information in accordance with the Health Insurance Portability and Accountability Act (HIPAA) Privacy Rule. Multiple algorithms can be configured since a combination of algorithms will be needed to deidentify the data correctly.

The Deidentification service takes an XML document as input. The first configured algorithm takes this document as input and modifies it in place. The result is fed into the next configured algorithm and so on. The result of the last configured algorithm is the XML document returned by the service.

Parameters:

The following table lists and describes the parameters common to all algorithm instances.

Parameter	Description
XML Namespace Provider	Provider for the mapping between XML namespace prefix and namespace URI in XPath expressions. If left blank, XPath expressions cannot contain namespaces.
Xpath Syntax	Determines which syntax level of XPath should be used. The default option selects the syntax level as set in the console global settings.

The following table lists and describes the parameters for the first algorithm instance.

Parameter	Description
Name1	Determines the de-identification algorithm to perform.
Argument1	The argument value for de-identification algorithms that take an argument .
Targetnodes1	An XPath expression that returns a nodeset. The de-identification algorithm will be applied to each node in the nodeset. If XML Namespace prefixes are used, they must be declared in the XML Namespace Provider.

For more information about the available algorithms and the meaning of the argument, see the following section.

Edges:

The following table lists the available line edges for the Deidentification Service (com.ibi.agents.XDDeidentifyAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse fail_operation

The Deidentification service offers explicit parameters for up to 5 algorithm instances: Algorithms 1 to 5. Extra instances can be created if more than five algorithm instances are needed. Instances for algorithm 6 and above can be created with user parameters named:

algorithmNN
argNN
targetNN

Where:

NN

Is the instance number.

For example, the sixth algorithm instance can be created with the user parameters: argument6, arg6, and target6. There is no limit on the value of NN, though the instance numbers must be consecutive to be recognized. The service stops looking for more algorithm instances as soon as it finds one that is not configured. For example, if Algorithm 3 is not configured, Algorithm 4 and 5 will be ignored.

Algorithms:

The following table describes the available alogrithms in the Deidentification service.

Algorithm	Argument	Description
Encrypt Formatted Digits	encryption key	Maps the digits in a formatted string with 4x4 Playfair algorithm. The encryption key should contain only digits, and is padded if necessary to make it 16 digits long. Playfair works with pairs of characters. When the number of digits in the input is odd, the input is padded by one character and one character is ignored in the output. There is no validation of the resulting number. The algorithm will always produce the same output for the same input when using the same key. The mapping is not reversible. Different input might map to the same output, though this is not common. Only the digits are mapped, the other characters are preserved at the same position. For example, (212)223-3333 might map to (655)887-2424 with the format characters preserved.
Encrypt SSN	encryption key	Maps Social Security Numbers by encrypting them with 4x4 Playfair algorithm. The encryption key should contain only digits, and is padded if necessary to make it 16 digits long. Playfair works with pairs of characters. The input is padded by one character. The output is 10 digits long and the last character is eliminated to make it 9 digits long. The algorithm will never produce a Social Security Number starting with 9, starting with 666, or with all zeroes in any of the three groups: 000-xx-xxxx, xxx-00-xxxx, and xxx-xx-0000. If the resulting Social Security Number is invalid, the output is re-encrypted until it becomes valid. The algorithm will always produce the same encrypted SSN for the same input SSN when using the same key. The mapping is not reversible. Different input SSN might map to the same encrypted SSN. Only the digits are mapped, while the other characters are preserved at the same position. For example, 111-22-3333 might map to 655-88-2233 with the hyphens preserved.
Sequential SSN	unused	Maps Social Security Numbers to numbers in consecutive increasing order starting with 001010001. The numbers produced adhere to the rule used by Social Security Administration on June 25, 2011 and later. The algorithm will never produce a Social Security Number with all zeroes in any of the three groups: 000-xx-xxxx, xxx-00-xxxx, and xxx-xx-00000. Only the digits are mapped, while the other characters are preserved at the same position. For example, 111-22-3333 might map to 001-01-0035 with the hyphens preserved. Within a single run, a previously mapped SSN will map to the same number it was assigned earlier. The mapping is not preserved across runs.
Text Constant	new text	Replaces the contents of an element by a string constant. The element keeps its attributes, but all existing mixed content children are removed. The argument is evaluated once to obtain the string constant.
Random Day	date pattern	Parses a date using the pattern in the argument, replaces the day and month with random values, and clips the year to at most 90 years ago. The argument is evaluated once to obtain the date pattern in SimpleDateFormat syntax.
Text Eval	iFL expression	Replaces the contents of an element by a string obtained by evaluating an iFL expression. The element keeps its attributes, but all existing mixed content children are removed. The argument is evaluated for each target node processed. The existing text value of the element is stored in the special register iway.value. The new value can depend on the existing value by calling _sreg (iway.value) within the iFL expression.
XML Constant	XML String	Replaces the contents of an element by a constant XML fragment. The element keeps its attributes, but all existing mixed content children are removed. The argument is evaluated once to obtain an XML string. The XML string is parsed for each target node, using the XML Namespace context of that node.
XML Delete	unused	Deletes the XML target nodes. The node itself, its attributes, and all mixed content children are removed.
XML Eval	iFL expression	Replaces an XML element by the result of an iFL expression parsed as XML. The node itself, its attributes, and all mixed content children are removed. The argument is evaluated for each target node processed. The resulting XML String is parsed using the XML Namespace context of the parent node. The first element of the resulting XML fragment is the new element replacing the target node. The new value can depend on the old value because the old element is passed as the root of the document during evaluation. For example, the _XPATH() function can be called to extract values from the old node.
XML Replace	XML String	Replaces an element by a constant XML element. The node itself, its attributes, and all mixed content children are removed. The argument is evaluated once to obtain an XML string. The XML string is parsed for each target node, using the XML Namespace context of the parent of that node. The first element of the resulting XML fragment is the new element replacing the target node.
Zip Keep First 3	unused	Keeps the first three digits of the five digit zip code followed by 00. The four digit code after the hyphen is ignored when present. For example, 10121-2898 becomes 10100.
Zip Keep last 2	unused	Keeps the last two digits of the five digit zip code preceded by 000. The four digit code after the hyphen is ignored when present. For example, 10121-2898 becomes 00021.

Example:

The following example shows the effect of various algorithms. The following table lists the parameter values.

Parameter	Value
Name 1	Sequential SSN
Target Nodes 1	/workforce/employee/ssn
Name 2	Text Constant
Argument 2	John Doe
Target Nodes 2	/workforce/employee/name
Name 3	Text Eval
Argument 3	_sreg(iway.value) - _imod(_sreg(iway.value),10)'-'_sreg(iway.value) - _imod(_sreg(iway.value),10) + 9
Target Nodes 3	/workforce/employee/age
Name 4	XML Constant
Argument 4	<street>1731 Technology Drive</street><city>San Jose</city><state>CA</state><zip>95110</zip>
Target Nodes 4	/workforce/employee/address
Name 5	XML Delete
Target Nodes 5	/workforce/employee/title

The following is a sample input document.

<workforce>
    <employee>
        <name>Harry Smith</name>
        <address>
            <street>2 Penn Plaza</street>
            <city>New York</city>
            <state>NY</state>
            <zip>10121</zip>
        </address>
        <title>Marketing Director</title>
        <age>48</age>
        <ssn>078-05-1120</ssn>
    </employee>
    <employee>
        <name>Mary Dickens</name>
        <address>
            <street>10375 Richmond</street>
            <city>Houston</city>
            <state>TX</state>
            <zip>77042</zip>
        </address>
        <title>Sales Engineer</title>
        <age>48</age>
        <ssn>165-16-7999</ssn>
    </employee>
</workforce>

The resulting service output is shown below.

<workforce>
    <employee>
        <name>John Doe</name>
        <address>
             <street>1731 Technology Drive</street>
            <city>San Jose</city>
            <state>CA</state>
            <zip>95110</zip>
        </address>
        <age>40-49</age>
        <ssn>001-01-0001</ssn>
    </employee>
    <employee>
        <name>John Doe</name>
        <address>
            <street>1731 Technology Drive</street>
            <city>San Jose</city>
            <state>CA</state>
            <zip>95110</zip>
        </address>
        <age>30-39</age>
        <ssn>001-01-0002</ssn>
    </employee>
</workforce>

Syntax:

com.ibi.agents.XDDocUpdateAgent

iIT Service Object:

document: Doc Update Agent

sreg: Doc Update Agent

transform: Activity Log Control

Description:

The Document Update service can be used to run find and replace procedures, and modify data based on static or dynamic parameters.

Note: This service requires a highly technical method to achieve the desired result. The same functionality can be performed through the use of a configured Transform component, which can be called by a Transform service. For more information, see Transform Service (com.ibi.agents.XDTransformAgent).

Parameters:

DS0 - document at time of build, DS#

The following image shows the New Service Object dialog in iIT Designer and the corresponding parameters that displays when you add a new Document Update service object to a process flow.

Edges:

The following table lists the available line edges for the Document Update Service (com.ibi.agents.XDDocUpdateAgent).

Line Edge	Description
OnError	Error: Returned by the service if any of the following fields contain an invalid iFL statement: Document Assembly Instructions DS1 DS2 DS3 DS4 Search Replace If Process to XML was selected and the document created is not a well formed XML document.
OnSuccess	Success: The service generated a successful output. Either a flat document was generated by the service (if Process to Flat text was selected), or a well formed XML document (if Process to XML was selected) was produced.
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse fail_operation: An unexpected error occurred while processing the document or the parameters of the service. Check the iSM logs for further details. fail_notfound

<Test>joe bill mike<Test>

Process to Flat text

Find/Replace then Build Document

ds0,ds1,ds2,ds3,ds4

_concat(this,' ')

_concat(is,' ')

_concat(a,' ')

bill

bill

buster

UTF-8

<Test>joe buster mike<Test>this is a bill

<Test>joe bill mike<Test>

Process to Flat text

Build Document then Find/Replace

ds0,ds1,ds2,ds3,ds4

_concat(this,' ')

_concat(is,' ')

_concat(a,' ')

bill

bill

buster

UTF-8

<Test>joe buster mike<Test>this is a buster

<Test>joe bill mike<Test>

Process to Flat text

Only Find/Replace

_concat(this,' ')

_concat(is,' ')

_concat(a,' ')

bill

bill

buster

UTF-8

<Test>joe buster mike<Test>

<Test>joe bill mike<Test>

Process to Flat text

Only Build Document

ds1,ds2,ds3,ds4

_concat(this,' ')

_concat(is,' ')

_concat(a,' ')

bill

bill

buster

UTF-8

this is a bill

<root><Joe>QA</Joe>

<Michael>QA</Michael></root>

Process to XML

Find/Replace then Build Document

_sreg(xmlrecord),DS0

QA

Quality Assurance

UTF-8

<?xml version="1.0" encoding="ISO-8859-1" ?>
<root>
    <Joe>QA</Joe>
    <Michael>Quality Assurance</Michael>
</root>

<Michael>QA</Michael></root>

Process to XML

Build Document then Find/Replace

_sreg(xmlrecord),DS0

QA

Quality Assurance

UTF-8

<?xml version="1.0" encoding="ISO-8859-1" ?>
<root>
    <Joe>Quality Assurance</Joe>
    <Michael>Quality Assurance</Michael>
</root>

<Michael>QA</Michael>

Process to XML

Only Find/Replace

QA

Quality Assurance

UTF-8

<?xml version="1.0" encoding="ISO-8859-1" ?>
<Michael>Quality Assurance</Michael>

<Michael>QA</Michael></root>

Process to XML

Only Build Document

_sreg(xmlrecord),DS0

QA

Quality Assurance

UTF-8

<?xml version="1.0" encoding="ISO-8859-1"  ?>
<root>
    <Joe>QA</Joe>
    <Michael>QA</Michael>
</root>

Syntax:

com.ibi.agents.XDCopyAgent

iIT Service Object:

control: Document copy

Description:

This service is used to duplicate an existing document. The service also allows a comment to be emitted and a delay to be configured. Unless a delay or comment is required, it is recommended to use the Move service instead.

Note: The delay parameter can be specified for benchmarking purposes, while the comment parameter is typically used during troubleshooting.

Example:

If running it with <test/> as the incoming message, the following is the result:

<?xml version="1.0" encoding="UTF-8" ?>
<test />

Edges:

The following table lists the available line edges for the Document Copy Service (com.ibi.agents.XDCopyAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure cancelled fail_parse

Syntax:

com.ibi.agents.XDAttachmentFromDocAgent

iIT Service Object:

attachments: Document to Attachment

Description:

This service adds a new attachment with the contents determined by the input document. The attachment headers are specified with user parameters. The name and value of the user parameter become the name and value of the header. Notice the value of the Content-ID header is taken as is, so the value must contain the surrounding angle brackets.

For example, a valid value for Content-ID might be <cid>. The Attachment Type parameter specifies the attachment Content-Type. If the Attachment Type is omitted, a Content-Type is chosen based on the document data:

• application/binary if the document contains bytes
• text/plain if the document is flat
• application/xml otherwise

The optional Attachment Name parameter controls the name sub-parameter of the Content-Type header. The Content-Type name can also be given directly in the Content-Type header value if desired.

The Body Result parameter specifies what to return in the output document: keep copies the input document to the output document, empty returns an empty document instead. This service follows OnSuccess upon successful execution, otherwise it follows the fail_attach edge.

Parameters:

Edges:

The following table lists the available line edges for the Document to Attachment Service (com.ibi.agents.XDAttachmentFromDocAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_attach fail_parse

Syntax:

com.ibi.agents.XDDQBatchExec

iIT Service Object:

DQS: DQS Batch Executor

Description:

This service is used to execute a batch command, which starts an iWay Data Quality Center (DQC) plan.

Parameters:

DQC_Home\runtime\bin\runcif.bat

Edges:

The following table lists the available line edges for the DQC Batch Executor Service (com.ibi.agents.XDDQBatchExec).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operation fail_parse fail_timeout

Syntax:

com.ibi.agents.MdcAgentISM

iIT Service Object:

DQS: DQS/MDS Flow Linkage

Description:

This service is used to invokes services in iWay Master Data Center (MDC).

Parameters:

Edges:

The following table lists the available line edges for the DQC/MDC Flow Linkage Service (com.ibi.agents.MdcAgentISM).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_operations fail_parse notfound

Syntax:

com.ibi.agents.XDEmailEmitAgent

iIT Service Object:

emit: Email Emit Agent

Description:

Emits an email to a specified mail host with various options, including the option to input data as an attachment.

Parameters:

Edges:

The following table lists the available line edges for the Email Emit Service (com.ibi.agents.XDEmailEmitAgent).

Line Edge	Description
OnError	Error
OnSuccess	Success
OnFailure	Failure
OnCustom	OnError OnSuccess OnFailure fail_parse fail_connect

Example:

To configure the Email Emit service, you must first specify the URL for your email server and the appropriate security level. The following example shows security settings that are configured for the Microsoft Exchange Server:

If your connection parameters are valid, you will receive an email notification that would context the incoming document and a response document from running the service, in the following format:

<?xml version="1.0" encoding="UTF-8" ?>
<emitStatus>
 <protocol>EMAIL</protocol>
 <parms>password=****, to=your_name@gmail.com, userid=js77777,
  docattachname=test.xml, usessl=STARTTLS, docattach=false,
  host=IBIUSMBSA.ibi.com, return=status, from=john.smith@ibi.com,
  subject=Email Emit Test</parms>
<status>0</status>
<msg />
<timestamp>2009-05-01T21:27:51.824Z</timestamp>
<attempts>1</attempts>
<name>your_name@gmail.com</name>
</emitStatus>

The following is an example of configuration settings for an Email Emit service object that includes an attachment in iIT Designer:

If your connection parameters are valid, you will receive an email attachment (test.doc) and a response document from running the service, in the following format:

<?xml version="1.0" encoding="UTF-8" ?>
<emitStatus>
 <protocol>EMAIL</protocol>
<parms>password=****, to=your_name@gmail.com, userid=js77777,
  docattachname=test.doc, usessl=STARTTLS, docattach=true,
  host=IBIUSMBSA.ibi.com, return=status, from=john.smith@ibi.com,
  subject=Email Emit Attch, docattachctype=text/plain, body=see
  attached</parms>
<status>0</status>
<msg />
<timestamp>2009-05-05T22:43:59.032Z</timestamp>
<attempts>1</attempts>
<name> your_name@gmail.com</name>
</emitStatus>