EXTENSIBILITY
The extensibility consists of following topics:
Background
OBDX is designed to help banks respond strategically to today’s business challenges, while also transforming their business models and processes to reduce operating costs and improve productivity across both front and back offices. It is a one-stop solution for a bank that seeks to leverage Oracle Fusion experience across its core banking operations across its retail and corporate offerings.
OBDX provides a unified yet scalable IT solution for a bank to manage its data and end-to-end business operations with an enriched user experience. It comprises pre-integrated enterprise applications leveraging and relying on the underlying Oracle Technology Stack to help reduce in-house integration and testing efforts.
Objective
While most product development can be accomplished via highly flexible system parameters and business rules, further competitive differentiation can be achieved via IT configuration & extension support. Time consuming, custom coding to enable region specific, site specific or bank specific customizations can be minimized by offering extension points and customization support which can be implemented by the bank and / or by partners.
Extensibility Objective
OBDX when extended & customized by the Bank and / or Partners results in reduced dependence on Oracle. As a result of this, the Bank does not have to align plans with Oracle’s release plans for getting certain customizations or product upgrades. The bank has the flexibility to choose and do the customizations themselves or have them done by partners.
One of the key considerations towards enabling extensibility in OBDX has been to ensure that the developed software can respond to future growth. This has been achieved by disciplined software development leading to cleaner dependencies, well defined interfaces and abstractions with corresponding reduction in high cohesion & coupling. Hence, the extensions are kept separate from Core – Bank can take advantage of OBDX Core upgrades as most extensions done for a previous release can sit directly on top of the upgraded version. This reduces testing effort thereby reducing overall costs of planning & taking up an upgrade. This would also improve TTM significantly as the bank enjoys the advantage of getting universal features through upgrades.
The broad guiding principles w.r.t. providing extensibility in OBDX are summarized below:
- Strategic intent for enabling customers and partners to extend the application.
- Internal development uses the same principles for client specific customizations.
- Localization packs.
- Extensions by Oracle Consultants, Oracle Partners, Banks or Bank Partners.
- Extensions through the addition of new functionality or modification of existing functionality.
- Planned focus on this area of the application.
- Standards based.
- Leverage large development pool for standards based technology.
- Developer tool sets provided for as part of JDeveloper and Eclipse for productivity.
Scope
The scope of this document is to explain the customization & extension of OBDX for the following use cases:
- Customizing OBDX application services and implement composite application services
- Adding pre-processing or post processing validations in the application services extension
- Adding Business Logic in pre hook or post hook points in the application services extension
- Altering the product behavior at customizations hooks provided as adapter calls in functional areas that are prone to change and in between modules that can be replaced (e.g. alerts, content management)
- Adding new fields to the OBDX domain model and including it on the corresponding screen.
- Defining the security related access and authorization policies
- Defining different security related rules, validator and processing logics
- Customizing OBDX UI
- Adding a new field or a table on the screen
- Removing fields from the UI
This document would be a useful tool for Oracle Consulting, bank IT and partners for customizing and extending the product.
The document is a developer’s extensibility guide and does not intend to work as a replacement of the functional specification which would be the primary resource covering the following:
- OBDX installation & configuration.
- OBDX parameterization as part of implementation.
- Functional solution and product user guide.
Out of scope
The scope of extensibility does not intend to suggest that OBDX is forward compatible.
Structure
This document is organized into following chapters
- Architecture of Service Tier: Provides overall architecture of the service tier of OBDX platform. This chapter will set the context for further chapters and also will introduce you to various terminologies that you will encounter throughout this document
- Extensible Points in Service Tier: Provides in depth knowledge about various extensible hooks available in the service tier.
- Architecture of GUI Tier: Provides overall architecture of the GUI tier of OBDX platform. This chapter will introduce you to various terminologies that you will encounter for UI extensibility.
- Extensible points in GUI Tier: Provides in depth knowledge about various extensible hooks available in the GUI tier.
- Libraries: Provides a listing of various libraries provided by OBDX out of the box along with their usage
- Workspace Setup: Provides step by step guidelines for setting up Eclipse workspace for extensibility
- Deployment: Provides information in packaging and deployment of the customized code on Weblogic server
- GUI Tier – Workspace Setup: Provides step by step guidelines for setting up workspace for GUI tier extensibility
- GUI Tier – Deployment: Provides information on packaging and deployment of customized GUI code on HTTP server
- Use Cases: This chapter discusses some of the extensibility points covered in earlier chapters with the help of some use cases.
Architecture of Service Tier
Let’s go through the building blocks of OBDX framework (also known as DIGX framework). To build a REST API, each of these framework components (as mentioned below) needs to be addressed and that’s why it becomes important to have a holistic idea about each of them. The arrangement of all of these framework components can be clearly understood in the following diagram:
- REST: The endpoint layer which gets invoked whenever a request URI is called. Also known as the layer which contains REST annotations and path to resources or sub-resources of an application
- Service: Also called as module layer of the framework. Generally, the core modules of DIGX application will have their own service implementation classes responsible for implementing core business logic, validation and security checks
- Assemblers: These are the mapping classes which convert data object containing request or response parameters into domain or database compatible form. These classes help us to get the required domain objects which can be further used in object-relational mapping
- Business Policy/ System Constraints: Before letting the query data read or persisted in the core application, certain business policies need to be validated. This separate layer of constraints check let the application behave as per the policies configured
- Domain/Entity: Represents the Java Object form of Database. This domain layer also contains data to be persisted or query response fetched through Object relational mapping
- Domain Repository: The term ‘repository’ denotes any data storage component. Each module of the application will have its own repository to manage its CRUD operations and that can be easily done using this component of the DIGX framework
- Domain Repository Adapter: Adapters are the connecting points to some external system and as the name suggests, this part of the framework contacts two kinds of repositories of DIGX application – Local Repository and Remote Repository. Eventually, the configured one out of these two will be invoked
- Adapters: Finally these are the adapter classes that can call either Local Database (DIGX specific tables) or Remote Repository (external system). Remote adapters can further be mocked if required
- External System/ Host: The core banking application such as UBS or OBP or any third-party application which operates final banking transactions.