Register
API Explorer
https://obp-api-sandbox.nmbbank.co.tz

Message Doc

OBP can communicate with core banking systems (CBS) and other back end services using a "Connector -> Adapter" approach.

The OBP Connector is a core part of the OBP-API and is written in Scala / Java and potentially other JVM languages.

The OBP Connector implements multiple functions / methods in a style that satisfies a particular transport / protocol such as HTTP REST, Akka or RabbitMq.

An OBP Adapter is a separate software component written in any programming language that responds to requests from the OBP Connector.

Requests are sent by the Connector to the Adapter (or a message queue).

The Adapter must satisfy the Connector method's request for data (or return an error).

"Message Docs" are used to define and document the request / response structure.

Message Docs are visible in the API Explorer.

Message Docs are also available over the Message Doc endpoints.

Each Message Doc relates to one OBP function / method.

The Message Doc includes:

  1. The Name of the internal OBP function / method e.g. getAccountsForUser
  2. The Outbound Message structure.
  3. The Inbound Message structure.
  4. The Connector name which denotes the protocol / transport used (e.g. REST, Akka, RabbitMq etc)
  5. Outbound / Inbound Topic
  6. A list of required Inbound fields
  7. A list of dependent endpoints.

The perspective is that of the OBP-API Connector i.e. the OBP Connector sends the message Out, and it receives the answer In.

The Outbound message contains several top level data structures:

  1. The outboundAdapterCallContext

This tells the Adapter about the specific REST call that triggered the request and contains the correlationId to uniquely identify the REST call, the consumerId to identify the API Consumer (App) and a generalContext which is a list of key / value pairs that give the Adapter additional custom information about the call.

  1. outboundAdapterAuthInfo

This tells the Adapter about the authenticated User that is making the call including: the userId, the userName, the userAuthContext (a list of key / value pairs that have been validated using SCA (see the UserAuthContext endpoints)) and other optional structures such as linked Customers and Views on Accounts to further identify the User.

  1. The body

The body contains named fields that are specific to each Function / Message Doc.

For instance, getTransaction might send the bankId, accountId and transactionId so the Adapter can route the request based on bankId and check User permissions on the AccountId before retrieving a Transaction.

The Inbound message

The Inbound message is the reply or response from the Adapter and has the following structure:

  1. The inboundAdapterCallContext

This is generally an echo of the outboundAdapterCallContext so the Connector can double check the target destination of the response.

  1. The status

This contains information about status of the response including any errorCode and a list of backendMessages.

  1. The data

This contains the named fields and their values which are specific to each Function / Message Doc.

The Outbound / Inbound Topics are used for routing in multi OBP instance / RabbitMq installations. (so OBP nodes only listen only to the correct Topics).

The dependent endpoints are listed to facilitate navigation in the API Explorer so integrators can test endpoints during integration.

Message Docs can be generated automatically using OBP code tools. Thus, it's possible to create custom connectors that follow specific protocol and structural patterns e.g. for message queue X over XML format Y.