Understanding SOAP_IFS

Contents

SOAP_IFS format

IFS Connect has the possibility to use an IFS specific SOAP format for transport of the IFS XML records.
The SOAP_IFS body is used to encapsulate the IFS XML record and the SOAP header is
defined by IFS like the example below :


The element <fndcn:Type> is the MessageType that categorize the message.
The element <fndcn:Function> is the element that is used for message identification.
Normally this field is equals to the BizApi name. For example RECEIVE_CUSTOMER_ORDER..
The element <fndcn:Receiver> identifies the receiver of the message.
The element <fndcn:Sender> identifies the sender of the message.
The element <fndcn:SentAt> is a timestamp when the message is sent.
The element <fndcn:ExpiresAt> is a timestamp that defines when the message should be obsolete.

All this elements above can be used by the Message Routing to route the inbound message to the correct destination(s).

IFS Connect is currently implementing the SOAP_IFS protocol for all included transport connectors and every new transport connector that is created will automatically use this envelopes.
 

Inbound asynchronous message flow

Post

An asynchronous message is sent to IFS Connect.
Note! The examples below show the IFS SOAP Gateway (HTTP reader) but it could be to any of the included readers in IFS Connect such as Mail, Ftp and File.

View example of an inbound asynchronous message.

OK Response

If a matching routing rule is found in the Message Routing (with a queue specified) the message will be posted to the queue system. A response message is returned to the sender.



View example of a asynchronous response message

Error response

If for example there is no matching routing rule found the message will be posted to the ERROR queue.
(Other type of errors can also give the same behavior)
Note! Only errors that are detected when trying to route and post to the queue system are handled here.
Error that occurs when the message is executed by the background process will not be visible here.
They will be visible in the queue system with messages in state FAILED.

If user is not authorized:
Post error: 401 Unauthorized

If the URL is incorrect:
Post error: 404 Not Found

Application errors from IFS SOAP Gateway:
HTTP: 500 Internal Server error and a SOAP error response message that follows the SOAP standard.
This message contains the detailed error description.

View example of an error message

 

Inbound synchronous message flow

Request

A synchronous request is sent to IFS Connect.
Note! The examples below show the IFS SOAP Gateway (HTTP reader) but it could be to any of the included readers in IFS Connect such as Mail, Ftp and File.



View example of an inbound synchronous message.

OK Response

If a matching routing rule is found in the Message Routing (without a queue specified) the actual BizAPI will be executed. A response message with the BizAPI result will be then returned to the sender.



View example of a synchronous response message

Error response

If user is not authorized:
Post error: 401 Unauthorized

If the URL is incorrect:
Post error: 404 Not Found

Application errors from IFS SOAP gateway:
HTTP: 500 Internal Server error and a SOAP error response message that follows the SOAP standard.
This message contains the detailed error description.

View example of an error message

 

Outbound asynchronous message flow

Post

An asynchronous message is sent out from IFS Connect queue system
Note! The examples below show the HTTP sender but it could be to any of the included senders in IFS Connect.



View example of an outbound asynchronous message.
 

OK Response

The receiving system should if everything is ok return a response message.
Note! The HTTP sender is synchronous by it's nature, thus the response can be a meaningful message with business data. For other senders, like File or FTP, it will be just a receipt about file being copied or sent to the destination.


 

View example of a asynchronous response message

Error response

An error response message that follows the SOAP standard should be returned to IFS Connect on any error in the receiving system.
This message should contain detailed error description.
HTTP 500 Internal Server error with error description should also be returned.

Note! This is only applicable from the HTTP sender. Not for other Connect senders.

View example of an error message

 

Outbound synchronous message flow

This is equivalent to Inbound synchronous message flow. Only directions are changed.

Request/Response