T3IRFX4 API Orchestration 201809
T3IRFX4 API Orchestration 201809
2
3
When using API orchestration, from the consumer perspective, it is a single API.
Internally multiple requests are combined to generate a response.
4
This exercise helps to practice chaining of T24 artefacts.
Instead of making 2 API calls to initiate payment order and subsequently view
payment status, orchestrating the 2 calls optimizes and enriches consumer
experience.
5
In order for T24 VERSION and ENQUIRY artefacts to be used in the Interaction
Framework, certain rules must be followed when creating the artefacts. These rules
provide a simple and effective governance framework.
6
The following rules must be followed when designing enquiries in T24
• ID must begin with XX.API, where XX is the module name and end with the version
number following semantic versioning rules -Major.Minor.Patch. They should be
named as collections. For e.g., ‘customers’ is a collection resource. A resource may
contain sub-collection resources. For e.g., ‘accounts’ of a particular ‘customer’
• Assign a data type to Enquiry columns using FIELD.DISPLAY.TYPE field. Fields are
considered to be alphanumeric unless they are set as Date or Amount. Amount
and Date fields MUST be unformatted, e.g. 20170123 and 1234.56.
• Supply a description in DESCRIPT field in the format verb/resource/subresource.
E.g., getAccountBalances. This is used to describe the operation supported.
• Use API style labels for FIELD.LABEL and SEL.LABEL – remove punctuation and
spaces, use camel case (MY.FIELD.LABEL > myFieldLabel), use complete words
(clearedBal > clearedBalance)
• Remove HEADER, static labels (literal in OPERATION) and drill down information
(ENQUIRY.NAME, SEL.CRIT, LABEL.FIELD, NXT.DESC). Set ATTRIBS to ‘’.
• Field names / resource names must exist in Temenos vocabulary to ensure
consistent names across all API initiatives
7
The following rules must be followed when designing versions in T24
• ID must begin with XX.API, where XX is the module name and end with the version
number following semantic versioning rules -Major.Minor.Patch.
• DESCRIPTION field is used as the Operation Id for the API. Use
verbCollectionResource pattern E.g., getAccountBalances
• Use API style labels for TEXT and PROMPT.TEXT.
• Use PROMPT.TEXT to signify that a field is a part of a collection (MV group) or a
collection of collections (SV group). For example, the fields chargeFor, chargeType
and chargeAmount are a multi value set. Setting the PROMPT.TEXT to charges
would result in the following JSON structure:
"charges": [ { "chargeFor": "string",
"chargeType": "string",
"chargeAmount": "string" } ]
8
9
In the workbench, click on create provider api from the API menu
10
Choose a domain for the service and amend the URL for the screen and query
suitably. Choose HTTP method as POST for the create a new payment order API.
In the query URL paymentOrderId is passed in path. Selection Mapping section maps
query URL parameters with T24 enquiry selection criteria fields. Map the enquiry
selection field ‘id’ with the query URL parameter ‘paymentOrderId’.
Click on Next.
11
The workbench generates an inventory of the selected T24 artefacts in JSON format.
12
13
14
• Create a service project provider-orchestrateT24 in design studio in the same
manner it was created previously.
• Extract the downloaded zip and copy the artefacts into the src > main > resource
folder.
• You should see the following set of generated artefacts
• Swagger definition – *-v1.0.0-swagger.json.
• Inventory json - *-v1.0.0-inventory.json.
• Camel XML – *-service-v1.0.0.xml.
• Mock responders - *-mock-v1.0.0.json.
• Test routines.
15
16
17
POST an initiate payment request using the endpoint URL defined for the service
18
To check the status, make a second API request using the status URL
19
To orchestrate the two API calls into a single request, amend the service xml
accordingly.
In the sample shown, the content based router of Apache camel is used, to
conditionally route to the payment order status query, if the initiate payment HTTP
response status code is 200 OK.
20
The same API request for payment initiation, generates a different response in
accordance with the routing rule in the service XML.
21
22
23
24
This exercise helps you to design a service which orchestrates a T24 API and an
external service. This service produces the aggregated response from T24 API and the
external service
25
Develop a Customer Inquiry API for the exercise and route to an external API as
described with parameters.
Enter the provider API project details in Workbench
For e.g.,
• Key – provider-orchestrate-external
• Title – Aggregator EIP example
26
• For ST.API.CUSTOMER.DETAILS.1.0.0, in the Selection Mapping Section, map
"customerId" field with “customerId" parameter and select the data type as string.
• For ST.API.CUSTOMER.LIST.1.0.0,
• in Main Parameter Section, amend service URL
• in URL Query Parameter Section, modify the URL parameters ‘nationalityId’
and ‘customerSector’ to a valid value in vocabulary. For e.g.,
customerSector is not a valid property in vocabulary. Change to sector.
• in the Selection Mapping Section, map the URL parameters nationalityId
and sector to corresponding enquiry selection fields
• click Next and Finish.
• Generate service artefacts and download from workbench
27
• Create a service project provider-orchestrate-external in design studio
• Extract the downloaded zip and copy the artefacts into src/main/resources folder.
• Build and install the service project provider-orchestrate-external.
• Add the service artefact dependency to the container projects’ pom.xml
• Verify the new service endpoints are listed in management service URL
28
29
Invoke customer list API by passing the query URL parameters specified at the time of
API design.
In the OFS that is constructed from the REST request, you can notice that the query
URL parameters become selection criteria fields of the enquiry
ENQUIRY.SELECT,,INPUTT/123456,ST.API.CUSTOMER.LIST.1.0.0,SECTOR
:EQ=1001,NATIONALITY:EQ=PA
30
Invoke customer details API using the URL specified at the time of API design.
In the constructed OFS, {customerId} in the query URL is mapped to the enquiry
selection criteria field @ID
ENQUIRY.SELECT,,INPUTT/123456,ST.API.CUSTOMER.DETAILS.1.0.0,@ID
:EQ=100100
31
In this lab exercise, for a specific customer, details are fetched from T24. Based on
the customers’ nationality in the response body a twitter target criteria is set and a
second call is made to twitter API. Simultaneously, mock response for customer
alerts are invoked.
In the sample shown, (1) a new API endpoint /{customerId}/summary is added. (2)
This REST endpoint routes the message first to the customer details route which
fetches customer information from T24. (3) The body of this response from T24 is
parsed for the nationalityId field. This fields’ value is used as target criteria for twitter
API. (4) The Multicast routes the same message to multiple endpoints simultaneously
– twitter and mock response for customer alerts. (5) The JSONAggregator strategy
reference assembles the replies from the multicasts into a single outgoing message.
By default Camel uses the last reply as the outgoing message.
Note: To invoke twitter API, make twitter jars available in your local repository in the
path com > temenos > irf > social. Add twitter dependency in the service project
pom.xml
32
Request to the endpoint /v1.0.0/party/customers/{customerId}/summary presents an
aggregated response of customer details query, twitter tweets for target=CNN and
customer alerts static mock response.
33
The aggregated response for the endpoint, show that the twitter response has
dynamically changed based on the twitter target set from the nationality field of
response body from T24. The static mock response is added to the response.
34
35
36
37