13. Acknowledgement scenario for outbound processing.

Introduction

Acknowledgment can be of system and application acknowledgment. System acknowledgment is a technical message send back to the caller to indicate that the data has been technically transferred. Application acknowledgment is to tell the caller that the data has been successfully processed without any business error. The acknowledgment can be sent to the caller back as a reaction of what he has sent to us. This is for inbound message. For the outbound message, we can only request from the receiving system to send us an acknowledgment or notification. We can request from the receiver to send us back the technical or application acknowledgment. A notification or acknowledgement message can be immediately e.g. send back from the receiver immediately for the outbound message or at a later time. In both cases, the acknowledgement message is an asynchronous message. If we make a synchronous call then we have immediately the response where we are waiting for that and get blocked until the response arrives. In this real synchronous case, we don't need acknowledgement or notification because the response is already the acknowledgement/notification message. Acknowledgement and notification make sense only for asynchronous messages. What should we provide for the outbound message? For the outbound interface, we can only request from the receiving system to send us the acknowledgment or notification. For acknowledgment, it is enough when we get only the application acknowledgment. We don't need a system acknowledgment.

Usecase to built the acknowledgement scenario for the inbound and outbound processing:

Create Adapter:

Type: SOAP

Create Property

Name Value

Endpoint : e http://110.74.222.147:9292/xml
Authentication : Basic
Operation : Post
Username: e … admin
Password : e … 12345

We can handle if the business has URL Query Parameter and HTTP Header

URL Query Parameter : ?pCity={!City}&pCountry={!Country}
HTTP Header : Content-Type:Application/xml|{!LastName}:{!FirstName}

2. Create Integration : i.e Testing-SOAPV3 Create Interfaces: Interface (inbound , outbound)

Name: Request-Interface, type outbound

Note: Chain Interface must be apply base on business.

Name: Response-Interface: type Inbound

4. Create Metadata Provider : Meta-SOAPV3 5. Create Repository : Repo-SOAPV3 6. Create MessageType : MessageType must define as SOAP Template -Here is SOAP tamplate created by Message Type for build xml payload: MessageType :Google SOAP Service Type : WSDL Service MessageType: Request Type: WSDL Request MessageType : HTPP Header Type : HTTP Header MessageType : URL Query Parameter Type : WSDL URL Query Parameter MessageType : SOAP Header Type : WSDL Header MessageType : SOAP Body Type : WSDL Body MessageType: Response Type: WSDL Response MessageType : HTPP Header Type : HTTP Header MessageType : SOAP Header Type : WSDL Header MessageType : SOAP Body Type : WSDL Body MessageType we have created:

Mapping of request:

With the message Type “Google SOAP Service” You can define with other Name but type is still WSDL Service Business MessageType: The business message Type could be in SOAP Header and SOAP Body Example : MyAccount, MyContact , MyCase

7. Create IStructure 8. Create MessageField Entry 9. Do Configuration with Request Interface(OutBound) Source/Target Message Type = Google SOAP Service 10. Do Mapping After finished configuration then you can Execute Callout CallOutControl c= new CallOutControl(); List r = IServices.invokeCalloutV3(‘Integration Name',Interface Name’,new String[]{'RecordId'},'SYNC',c); System.debug(r); 11. Look back to the Point 1 you see the Property name URL Query Parameter and HTTP Header

If we execute callout with input param like queryparam and headerparam the value we replace on property name URL Query Parameter and HTTP Headeris base on CallOutControl input param, but if we don’t use this case the value will replace by mapping.

Example of input with CallOutControl CallOutControl c= new CallOutControl(); Map queryparam= new Map(); queryparam.put('City','Mumbai'); queryparam.put('Country','India'); Map headerparam= new Map(); headerparam.put('LastName','Patil'); headerparam.put('FirstName','Shweta'); c.queryParam(queryparam); c.headerParam(headerparam); List r = IServices.invokeCalloutV3(‘Integration Name',Interface Name’,new String[]{'RecordId'},'SYNC',c);

Example of value base on Mapping:

We create IStructure for URL Query Parameter and HTTP Header

IStructure of URL Query Parameter

for example, 1- City 2- Country

IStructure of HTTP Header

for example 1- LastName 2- FirstName

And do mapping from Source field to Target field of these MessageType.

Following the URL Query Paramter: After we have replaced the value, then the value of property URL Query Paramter will be link with the Property Endpoint.

Example : http://110.74.222.147:9292/xml?pCity=PhnomPenh&pCountry=Cambodia

Following the HTTP Header: After we have replaced the value

Example: Content-Type:Application/xml|Yan:Ranin

Response Result (Inbound): If the Response is success our functionality will create root API message for both Messages (Request and Response) and API of Request and Response message will link to each other. Otherwise if the Callout request failed and response with fault, Currently messages request will update to failed and fault error will put into the Messages comment. Here is some of to do mapping in response interface : We using the existing Response Message type that we have created in the Message Type Google SOAP Service for link to Interface response.

Currently our inbound processing is working only response with body, so the business response is must in the MessageType SOAP Body. We can do mapping from the messagetype “MyAccount” map to Node Target sObject “Account”. And then do map source field to target field. For the example you can testing with Mock Service and with the Fake response. The Result of API Messages of Request and Response: