Application Lifecycle and Multitenancy
In the back end, the APIs live in tenants - data isolation layers between legal entities, such as banks or other financial institutions, that are usually hosted on-premise.
There is a strong relationship between the application lifecycle and the multitenancy operation mode of FusionFabric.cloud.
Promotion Stages
Finastra Sandbox
When you register an application on FusionCreator, you get, by default, access to APIs from the Sandbox tenant, that are backed by live instances of core systems. Thus, you experience the interaction with a real environment, very similar to what you can get from a production environment.
At this stage, your application is in development mode. The other promotion stages that your application can reside into are testing and production.
Promotion Stages.
Other Tenants
There are other tenants available, for each of the promotion stage, including development.
The financial institutions that are registered as tenants on FusionFabric.cloud can maintain
several tenants, identified by a <%tenant-id%>, that correspond to stage environments,
as follows:
- Development: contains data maintained by the financial institution, that can be used for development or test purposes.
- Test (UAT): contains data that replicates a live core system, usually used for validation by the financial institution.
- Production: contains data connected to a live core system maintained by the financial institution.
The following table summarizes the relation between the promotion stages and the tenants:
| Promotion Stage | Tenant | Tenant ID |
|---|---|---|
| Development | Finastra Sandbox Any other Development tenant |
|
| Test (UAT) | Any Test (UAT) tenant | <$tenant-id%> |
| Production | Any Production tenant | <$tenant-id%> |
When you promote your application to other stages, you let other tenant owners know that your application is ready to be tested against real core systems data. For this reason you have to be aware of the following topics:
- You must update the Discovery service URLs in your client application to account for the tenant change. To read more about the Discovery service, see the OAuth2 Authorization section.
- You must confirm that the reply URL that you have used when you registered the application is still valid. If not, you are required to provide a valid one. To read about the reply URL, see the Authorization Code Grant Flow.
- The set of application credentials are not valid anymore. You need to regenerate them and make sure you update your client application to use the new set of credentials. If your application uses APIs from different channels, you need to regenerate the credentials for all of them.
Promotion Process
To make the deliverable code available for real core systems, an application must make its way through the promotion stages. This is the complete process an application must promote before you can release it for financial institutions.
Your application has progressive access to the tenants of each promotion stage. For example, when an application is promoted to a Testing (UAT) environment, it can access data from tenants with DEV and UAT for further tests. The same thing happens for Production tenants.
When an application is promoted to a new stage, client secrets must be generated again. To promote an application from Testing(UAT) to Production, billing details must be provided first. Read more on User Entitlements section.
Application Version Release
When changes or fixes need to be pushed into an application already available in Production, a second version of the application must be delivered.
It is always possible to modify an application while in Development. When the new deliverable version is promoted to the next stage, a development release is generated with a unique Promotion ID assigned to identify the promotion. This way new versions can be created and tested while keeping the old stable version up and running into Production environments.