UNICOM® Digital Transformation Toolkit (UDTT™) provides an architecture and a class library that facilitate the structuring and development of teller applications, by promoting reuse of transactions and providing the services required to process them. The toolkit is based on the following base core entities (operations, flows, data elements, formatters, CHA (contexts), services, and invokers), the Event Manager, Element Factory (IoC container) and Initialization Manager which loads toolkit components in a configurable way.
The operations, flows, data elements, formatters, CHA (contexts), and services interact as follows. An operation flow (the execution process of the operation or flow processor) is the whole set of tasks required to complete a basic financial transaction, including data input and validation, interaction with external services, and management of the results and data that are received. An operation step is an entity that represents the set of interactions with the services that are required for a specific operation. Operation steps are managed by operations, and each operation's definition specifies the operation steps it will use.
Operations manage two basic attribute sets:
▪ The operation context, the context from which the operation flow requests the services to be used; requests that the data be formatted and sent to the services; and requests that the data received from the services is stored after it is interpreted.
▪ The formatting services: the entities that are used to build the formatted data that is interchanged with the services and to interpret the data received from them. Services provide high-level application functions to fully support objects such as host communications, printers, and many others. Each service extends the class Service and implements its own interface. This provides externalization of parameters and a standard way to signal events. Normally, the service protocol accepts as arguments either an already formatted object or a context and the formatter to be used. Services can work totally asynchronously.
An operation flow is normally common to many different operations, with the only differences being the data elements and the formatters that are used in the interaction with the services. Because these differences can be handled by the formatting services, an operation flow is by nature a highly reusable part. Tasks inside the operation flow result in one or many operation steps. Operation steps are also highly reusable pieces of code that can be used by many different operations.
A business operation has two main parts: the view, where the user enters the request data and receives the response, and the model, the code that executes the logic of the operation.
A specific business operation may involve the following: on the client machine, there may be an operation view and an operation model corresponding to an operation flow (for example, getting data from a magnetic reader, sending/receiving data to/from the server side, and printing a receipt on a local printer). On the server side, a different operation model, with its corresponding flow, is launched automatically: This operation model receives the request from the client machine and processes the specific tasks for the operation on the server (for example, adds an entry in the journal, sends/receives data to/from the host, updates the journal, and prints a report on a laser printer on the server).
When an operation is being performed, all the global data and services required by the application can be grouped into different sets of related information. Each of these sets of information logically belongs to a different type of banking entity: some related to the user, some to the branch, some to the client, some to the server, some to the whole banking institution, and so on.
Each of these sets of related data and services makes up a context.
Each operation model has its own context, the operation context, with a specific set of operation data that includes elements for data input and for data received from external sources (host, local DBMS, etc.) Because the operation context is part of the context structure, the operation can access data at different levels in the context chain. When a service is requested, the operation will use the more specific service associated with the identification defined in the context chain. The data used by an application can be considered as a context hierarchy, where each context level is able to provide the information it contains or the information belonging to contexts in upper levels.
An operation performed in a client/server environment has an operation context on the client and an operation context on the server. Each operation context is chained to one of the existing contexts when the operation is initiated.