Configuring Interfaces to FTI / SWIFT gateway
Understanding translation processes:
The flows are divided into three categories:
- Core
- MT to XT
- XT to MT
Core
Core flows consist of two flows:
- MT-MX translator
- FTI listener
MT to MX translator excepts MT message from the FTI application. The exchange of MT messages is configurable, i.e; the message exchange may take place via Active MQ or IBM MQ.
The trigger point of the processes to pull the MT message from the interfaces. Refer to the screenshot below. Fiorano MQ series microservice renamed as "FTI_IN" is used to subscribe to messages from IBM MQ.
Refer to the MQSeriesOut documentation on how to configure IBM MQ endpoints.
To configure a JMS MQ endpoint ( like Active MQ), the existing MQseries microservice should be replaced with a JMS adaptor from the microservice repository and then configure the JMS credentials and MQ details.
Click JMSOut4.0 for details.
Translation
The MT messages are translated via flows saved under the MT_To_MX category.
SWIFT gateway – Uploading MX messages
MX message generated is then written into a local file in the Fiorano server using the Fiorano FileWriter microservice. The folder where the MX files are generated is assumed to be interfaced with the SWIFT gateway. Here the filewriter is named as "MXResponseWriter".
Depending on SWIFT message gateway interface, appropriate Fiorano microservices such as FTP / MQ / JMS MQ / WS web service, etc. are to be used.
MX-MT Translator
The incoming MX message from the SWIFT gateway is read from a file folder. The files are read from the Fiorano server folder. File Reader microservice reads the files from the MX source folder; the files/messages are received from the local folder.
Depending on the interface, appropriate microservices have to be used.
After translation, the MT messages are sent to the interface supported by FTI as explained in the above process.
MT to MX
This section includes the prebuilt processes that convert incoming MT to its relevant MX.
MX to MT
This section includes those processes that convert the MX messages to relevant MT messages.
Named Configuration
Various parameters/properties configured within each component can be saved with a specific name that can be reused in similar components. For eg; MQ connection properties. FTI MQ properties are saved with a name under the Named Configuration attribute in the Connection Configuration property dialog box.
Once these configurations are saved as named configurations, changes can be done from a single window as shown in the screenshot below.
Refer to the Defining Named Configuration and utilize EPLCM section.
Adding a resource to a component
There may be dependencies on some libraries while using different components. For eg: the MQ series component to connect to IBM WebSphere MQ needs IBM MQ client libraries. These resources have to be added to the microservice.
Following are the contents extracted from the Adding Resources to a Microservice section.
The resources required for a particular component need to be added to its class path so that the program can access and utilize them properly and effectively, which ultimately helps the smooth functioning of the overall application. It can be added during configuration or during runtime. Resources can be of any type such as dil, zip, jar and exe. To add resources to a component, edit the respective component, or the corresponding system library present in the Microservice Repository, using eStudio application. Instructions for adding resources are illustrated below by taking DB component as an example. Considering the DB component as the example, the point to be noted is that all the components under DB category such as DB, DBProc, DBQuery, and DBQueryOnInput share a common System Library (jdbc) which handles the JDBC connection. Hence, add JDBC drivers as resources to JDBC System Library, instead of adding them separately for each component under the DB category. Login to the Enterprise Server in eStudio application and follow the below steps: Close the ServiceDescriptor.xml window to apply the changes to all the associated instances of this microservice. Changes are saved only when this window is closed. Do not stop instances: Choose this option if you are running any Event Process which you do not want to stop. The new resources will be added when the instance is run next time, but the cache component has to be disabled as explained in the next step. The below resources required for JMS and MQSeries components can be added in the same manner. For example, JMSAdapters:4.0 added to JMS category applies to all the three components involved as below. Category Components Involved Resource Needed JMS JMSIn 4.0, JMSOut 4.0 and JMSRequestor 4.0 JMSAdapters:4.0 JMS JMSIn 5.0, JMSOut 5.0 and JMSRequestor 5.0 JMSCommon:4.0 MQSeries MQSeriesIn 4.0 and MQSeriesOut 4.0 MQSeries:4.0Overview
Procedure and Prerequisites
Before starting with the steps, ensure that the Enterprise Server is started and is running.Adding Resources for DB Category components
Figure 1: Opening Microservice Repository panel
Figure 2: Expanding System Lib service
Figure 3: Navigating to Editing Service
Figure 4: Alert saying that the changes will be saved only after the editor gets closed
Figure 5: Maximizing the ServiceDescriptor.xml window
Figure 6: Navigating to Resource section to choose the resource
Figure 7: Choosing the resource by browsing to the system location
Figure 8: Saving the changes made by adding the new resource
The resource gets added to the component on the event of next execution.Resources for JMS and MQSeries