Remote Process Invocation

Remote Process Invocation (RPI) allows you to easily share data and processes throughout multiple independently built applications. For example, if a banking or insurance application requires financial data from another application, it simply makes a call to that application to retrieve it.

There are two ways for an application to obtain the needed information without affecting its data integrity:

Request and Reply

The request and reply or request and response pattern is a procedure used for applications to communicate with each other. It's considered one of the most basic methods and it consists in a request made by the first application and a second one responding with the request information.

Using this pattern, the FintechOS platform calls the remote system and then waits for the completion to be successful. If the completion is successful, the remote system synchronously replies with the requested data. In addition to this transaction, the FintechOS platform could update its information in the database or trigger another type of event.

The below table shows you how to start the process, request the required information, and then receive a response from the remote system, to eventually use the data received and make updates within your FintechOS application.

Procedure Fit Description
Invoke REST service from a server-automation script Optimal The FintechOS platform allows you to invoke an externally hosted service by calling its exposed APIs via server-automations scripts.
Generate SOAP or OpenAPI clients. Optimal The FintechOS platform enables you to generate clients using WebAPI import capabilities:
  • Generate REST client using OpenAPI specifications of the client’s API.
  • Generate SOAP client by importing the client’s WSDL.
The generated code provides the necessary logic to call the remote service. It can be used in a server automation script
 

For this pattern, the FintechOS platform uses web service as a calling mechanism. For example, in an insurance scenario, searching the Siwalu database to verify pet breeds. The results are retrieved immediately and displayed in your FintechOS solution.

The below table highlights the FintechOS platform properties best suited for the request and reply pattern.

PropertyMandatoryDesirable

Not Required

Event handling X 
Protocol conversion X 
Translation and transformation X 
Queuing and buffering X 
Synchronous transport protocolsX  
Asynchronous transport protocols  X
Mediation routing X 
Process choreography and service orchestration X 
Transactionality (encryption, signing, reliable delivery, transaction management) X 
Routing  X
Extract, transform, and load  X
Long polling  X
MethodStrategy Description
Error handlingWhen error codes or exceptions are returned to the caller, the caller manages error handling. For example, an error message displayed on your logging page that needs further action.
Error recoveryUnless the caller receives a successful response, changes aren't committed to the FintechOS platform. For example, when onboarding a new customer, the identity verification process cannot be completed unless a successful response is received. If necessary, the operation can be repeated.

Idempotence

To ensure data integrity, the remote procedure called must have idempotent capabilities. Idempotency allows you to execute the same call many times and receive the same result. It cannot be guaranteed that the FintechOS platform makes only one call, or that other processes do the same.

It's important to track duplicates based on unique message identifiers sent by the customer. Also, upsert operations must be performed.

Security

The following security considerations are specific to using SOAP and HTTP calls in this pattern.

  • Implement Two-way Server Certificate Authentication (SSL) with both self-signed and Certificate Authority (CA) signed.
  • Implement an appropriate firewall mechanism to protect the remote system.

Data Volumes

The response-reply pattern is used for small volume, real-time activities, due to the small timeout values and maximum size of the request or response. This pattern should not be used in batch processing activities in which the data payload is contained in the message.

The below diagram illustrates the FintechOS platform calling out to a remote system (synchronous remote process invocation).

  1. An action is initiated on the FintechOS Portal web page. For example, by clicking a button.
  2. The browser performs a HTTP POST request that sequentially performs an action on the corresponding service.
  3. The actual call to the remote service is invoked by the controller.
  4. The controller receives the response from the remote system. The controller processes the response, updates the necessary data in the FintechOS platform, and re-renders the page.
NOTE  
If the subsequent state must be tracked, the remote system returns a unique identifier that is stored in the FintechOS record.

 

Fire and Forget

The fire and forget is a procedure where a request is made from an application to another with no attempt to track the response. This mean that the request reaches the network, but no other check is made.

Using this pattern, the FintechOS platform calls the remote system but doesn’t wait for the call’s successful completion. As an option, you can receive the outcome of the initial call in a separate transaction.

The below table shows you how to start the process, request the required information, and then receive a response from the remote system, to eventually use the data received and make updates within your FintechOS application.

ProcedureFitDescription
Outbound calls and CallbacksGoodCallbacks ensure a way to reduce the effect of out-of-sequence messaging. Also, they handle the below scenarios:
  • Idempotency - Outbound messages perform retry attempts in case the acknowledgment isn’t received in a timely manner.
  • Retrieving more data - An outbound message can send data only for a single object. A callback retrieves data from other related records, such as related lists associated with the parent object.
MethodStrategy Description
Error handlingAs this pattern is asynchronous, the remote system is in charge of error handling. For outbound messaging, if there is no positive acknowledgment received within a defined timeout period, the FintechOS platform initiates a retry operation.
Error recoveryAs this pattern is asynchronous, the system must initiate retries based on the service’s quality-of-service requirements. For outbound messaging, if there is no positive acknowledgment received within a defined timeout period, the FintechOS platform initiates a retry operation.
Failed messages are placed in a queue monitored by administrators. If necessary, the retry operation can be done manually.

Idempotence

The remote service should be able to handle messages from the FintechOS platform in an idempotent manner as this pattern is asynchronous and retries are initiated when no positive acknowledgment is received.

Every outbound message sends a unique ID that remains the same throughout the retry process. Duplicate messages can be tracked based on this unique ID to ensure duplicate record are not created.

In addition, the idempotent considerations in the request and reply patter apply to the fire and forget pattern.

Security

The following security considerations are specific to using HTTP calls in this pattern.

  • Implement Two-way Server Certificate Authentication (SSL) with both self-signed and Certificate Authority (CA) signed.
  • Implement an appropriate firewall mechanism to protect the remote system.
  • Implement one-way hashes or digital signatures.

The below diagram illustrates a call triggered by create/ update operations. The clal is made from the FintechOD platform to a remote system.

  1. An update/ insert operation occurs on a record in the FintechOS platform.
  2. The process is triggered when a set of conditions is met and a request is created.
  3. The created request is sent to the customer via Service Pipes.
  4. The customer's application receives the message request and internal computations begin.
  5. A callback is performed to update the initial data in the FintechOS platform.

An e-commerce company uses the FintechOS platform to provide financial services for its clients. To accomplish this, a payment service provider is integrated with the FintechOS platform.

A user orders something so the e-commerce company forwards the requests to the FintechOS platform which, after some internal checks, decides that it can call the service provider to perform the actual payment. After the payment is performed the payment service provider notifies the FintechOS platform using a callback.

The below constraints apply.

  • The payment authorization can’t be synchronous because the service provider must perform additional checks before the payment can be confirmed.

On the FintechOS platform side:

  • Create an endpoint that receives the order request from the e-commerce company and creates the order in the database.
  • Create an automation script that carries some checks on the data from the request, creates and sends a request to the payment service provider.
  • Create an endpoint that receives the callback from the payment service and updates the order in the database.

On the remote system side:

  • Create an endpoint that receives the payment authorization request.
  • Create a service that calls the FintechOS platform with the status of the payment.

This example demonstrates the following.

  • Implementation of a remote process invoked asynchronously.
  • Subsequent callback to the FintechOS platform to update the state of the record.