BizAPI

jhmase: Overlook language and use uniform descriptions of the different BizAPI functionality

BizAPIs are grouped by a combination of characteristics. The characteristic categories are the Message Direction and the Protocol Type. This page aims to sort out the differences between the different types of BizAPIs that exists in the set of valid combinations. 

Contents

• BizAPI categories
• Message flow for an Inbound BizAPI
• Message flow for an Inbound Request BizAPI
• Message flow for an Outbound BizAPI
• Message flow for an Outbound Request BizAPI

BizAPI categories

 The first part of the BizAPI category is the message direction:

• Inbound : A BizAPI that handles incoming messages being sent to IFS Applications.
  This BizAPI type is implemented in Java using the middle tier Java Server Framework Note: This is only available on sites with an IFS Development License.
• Outbound : A BizAPI that handles outgoing messages from IFS Applications.
  These messages are sent from PL/SQL using the PLSQL Access Provider. Note: This is only available on sites with an IFS Development License.

  
  A message containing only key values should be created using PL/SQL and the BizAPI Java implementation should get and add the rest of the information. 
  The complete message can be created in PL/SQL but this may lead to performance problems when messages are large.
  (There is also a simplified way to send outbound messages without creating a BizAPI.) How? Should include a link!

The second part of the category indicates whether the BizAPI is of the type request/response.

• Request/response type:  These are messages that have a synchronous response returned and assumes a short-lived transaction. Examples are: CHECK_AVAILABILITY, LIST_PRICES. These messages are always synchronous and don't use message queues.
• Not of the request/response type: These are documents that are submitted to an application or system. They are often part of a long-lived transaction. Examples of this are RECEIVE_CUSTOMER_ORDER, SEND_ORDER_RESPONSE. These messages are always asynchronous and use message queues for batch execution.

These combinations define four different categories.

Message flow for an Inbound BizAPI

1. A connector reader receives the message, calls the Message Router and waits for a response from the queue system.
2. The Message Router determines which BizAPI to invoke and if any transformer should be applied.
3. The Message Router resolves also all optional destination addresses.
4. The Message Router posts the message to the IN queue and sends back a receipt to the connect reader. If any errors occur the message is posted to the ERROR queue instead.
5. The Batch Server polls the IN queue, picks up the message and starts execution of the destination addresses.
6. The message will be transformed to IFS XML format if any transformer is to be applied.
7. The invoked BizAPI calls the actual business logic stored procedure and sends the response back to the Batch Server. If response is ok, the message state is changed to FINISHED, otherwise to FAILED.
8. If an optional response address is defined, the response will be transformed (if any transformer is defined), put into a SOAP enveloped and sent to the defined destination.

Message flow for an Inbound Request BizAPI

1. A connect reader receives the message, calls the Message Router and waits for a response.
2. The Message Router determines which BizAPI to invoke and if any transformers should be applied.
3. The Message Router resolves all optional destination addresses.
4. The Message Router executes the destination addresses and waits for a response.
5. The message will be transformed to IFS XML format if any transformer is to be applied.
6. The called BizAPI calls the actual business logic stored procedure and returns the response back to the calling connect reader.

Message flow for an Outbound BizAPI

1. The record is created by the PL/SQL Access Provider and is posted to the OUT queue using the Post_Outbound_BizAPI stored procedure.
2. The Batch Server polls the OUT queue, picks up the record and invokes the BizAPI. Typically the record contains only key values, thus the BizAPI fetch the additional data from the database using the sent keys and then creates and returns the message.
3. After BizAPI execution the Message Router is called to resolve destination addresses based on contents of the in and out data to and from the BizAPI and also content of the record created by PL/SQL Access Provider.
4. The out message will be transformed from IFS XML to any format if a transformer is about to be applied.
5. The message will be embedded into a SOAP envelope if necessary.
6. The connector sends the message to the destination using its native protocol. If response is OK, message state is changed to FINISHED, otherwise FAILED. Some connectors are designed to resend the message in case of failure.
7. If an optional response address is defined, the response will be transformed (if any transformer is defined) and sent to the defined destination.

Message flow for an Outbound Request BizAPI

1. The record is created using the PL/SQL Access Provider and SOAP Gateway is invoked using the Invoke_Outbound_Request_BizAPI stored procedure of the PL/SQL Access Provider, which then waits for a response.
2. SOAP Gateway calls the corresponding outbound BizAPI.
3. SOAP Gateway calls the Message Router, which determines the connector sender(s) to run and if any transformers and/or envelope(s) should be applied.
4. The Message Router executes the destination address and waits for a response.
5. The message will be transformed, if necessary.
6. The message will be embedded into an envelope, if necessary.
7. The connector sender sends the message to the destination using its native protocol. The response is returned back to the Invoke_Outbound_Request_BizAPI procedure. Typically HTTP is the connector sender used in this scenario.