Fund

Functional requirements

Fund sample is an implementation of fund management. The following implementations are available:

  • Query customer account list and details

  • Query position fund list

  • Query fund product list

  • Process a fund product purchase sub-flow.

  • Add a fund product to customer’s interested list sub-flow.

  • Query customer interested fund product list

Operations

The operations supplied for this application are samples to illustrate what would be presented in a typical internet banking application.

The sample application has an operation that connects to the server to establish a session and create a new context for the user (StartUpHtmlSessionOp).

The sample has the following operations to support the transactions:
  • Web service operations that lists all accounts (wsAccount_GetAccountSummary) and related sub-accounts list (wsAccount_GetSubAccountList).

  • A reusable operation for implementing risk assessment (checkRiskAssessOp) in fundBuySubFlow.

  • A reusable operation for implementing customer account balance check (checkBalanceOp) in fundBuySubFlow.

  • A web service operation that interacts with backend services to create a fund purchase record (wsProduct_BuyFund).

  • An operation that interacts with backend database to create a fund purchase electronic journal record (fundBuyEJOp).

  • Three web service operations that interact with backend services to add one selected fund record to customer’s interested list (wsProduct_AddToInterestedFund), get customer’s fund position list (wsProduct_GetFundPosition) and get customer’s interested fund list (wsProduct_GetInterestedFund).

  • A web service operation that processes the customer's query condition and return query result (wsProduct_QueryFundProduct.transaction).

Please refer to related *.transaction files for details.

Context hierarchy

The contexts used in the application are arranged in a hierarchy starting at the top with the server root context. The root context, in addition to maintaining session tables for all the clients that connect to the server, keeps all the resources (data and services) shared by all the processes and operations launched from any session established on the server.

Whenever a session is established on the server, the startUpHtmlSessionOp operation creates an htmlSession context and chains it to the root context. This session context keeps all the resources that processes and operations used during the user session. Services must be properly attached to this context so that they are created only when the session is created instead of being created whenever the user requests an operation.

The toolkit chains all the processes and operations used during the session to their own copies of the session context. These contexts store data for the processes and operations.

Please refer to src/definitions/processors/*.transaction files for details.

Data elements and formatter

Data elements are structures in which toolkit entities, processes, and services hold data for further operations, like adding, updating, and deleting during runtime.

In the Internet Banking sample, data elements are defined as below.

Formatters provide the way of transforming one format to another so that various entities, processes, and services can use the data. In the definition files for the Internet Banking Sample Application, all formats shown in the following figure are defined by mapping. Please refer to Defining data mappings.

Navigation flows

This is the main component of the architecture being used by the Internet Banking Sample. It provides process management and transactions support. The application implements navigation processes as state machines (processors) and transactions as operations.

The fund purchase process is the only business operation in the Internet Banking Sample Application that requires a navigation flow. This process accepts and processes fund account query, enabling a customer of the Internet Banking Application to query fund product. The process may optionally call a subflow to collect purchase information from the customer to finish fund purchase, or call a subflow to add selected fund product into customer’s interested list. The application provides the subflow to demonstrate the main capabilities of the toolkit architecture and reflect the real business world in which some complex business flows are required. In summary, the following navigation processes are used for the application:

  • A fund management process (fundFlow.transaction)

  • A fund purchase process (fundBuySubFlow.transaction)

  • Add selected fund into interested list process (fundInterestedSubFlow.transaction)

Please refer to src/definitions/processors/*.transaction files for details.

User interface pages

The BTT XUI editor is a WYSIWYG (what you see is what you get) tool that enables you to design and create user interfaces. XUI is an abbreviation for XML User interface.

Eight XUI pages have been implemented in this sample. Please refer to the Table in Sample implementation for details.

The following figure shows one user interface page named fund_main.xui designed with XUI editor.

Then XUI editor generates fund_main.jsp file from fund_main.xui, as shown as followed: