|
|
| |
Flexible Solutions on Oracle Middleware - Comprehensive business solutions
- Area solutions with flexible customization options
|
|
|
|
|
Technological Features
The GOTS-SCD-SMS systems cooperate closely in serving customer requests.
The GOTS is responsible for the integrated handling of the large number of transactions coming in from the different presentation layer applications and other background systems. This includes transaction logging, storing and their uploading into the background system. Transactions coming from different channels can be viewed and handled on an integrated single interface. GOTS holds up the transactions that cannot be sent in due to background system problems or business rules, and it forwards them to the background system as soon as it becomes possible. The GOTS has a framework-like design; the actual background systems can be adapted with plug-ins. These complete components are standalone installation units, they can be released separately. GOTS receives transmittable transactions through queues, and it also sends its item status change responses here. Currently it comes with JMS Queue, MQSeries and Oracle Advanced Queue conduits.
Inasmuch as the transmittable transactions coming from the legacy systems can only be produced as files, then it can read them with the FileProcessor (FPROC) component and send it to GOTS via JMS queue. In the GOTS, the item reception and the execution logics are separated. The incoming items are always stored in a database in order to avoid loss in any circumstances. The items process through the elements of a well defined set of stages, so it is possible to manage the background system failures, as well as situations when a transaction is already received but it is going to be processed later, so that its execution should be checked in another time. The sender system will be notified with messages upon any transaction state changes.
The GOTS uses internal execution queues that may be priorized, so transactions received from a priority channel will enjoy advantage. The system uses a batch-level sequence for the incoming items. The SCD application stores contract data in a meta-structured database and the related operations can be accessed through a WebService interface. Inasmuch as there is no need to set up any relations between the fields on the contract recording screen, new contract types may be formed without programming. Based on contract data, SCD’s fee calculating component creates the scheduled chargeable sums based on monthly and ad hoc fees for every customer, and then it sends these transactions to the accounting system with the help of GOTS. The SMS System is capable of sending both ad hoc and bulk messages (SMS and e-mail). It receives notifications about events occurred in the accounting and card system (e.g. charges), and using the information in the SCD system it can be decided whether it is necessary to send SMS to the customer in the particular case. If yes, then the message will be sent and the certain entry will be made in the log database. The SMS System also makes scheduled information requests from the accounting systems (e.g. account balance), and sends out corresponding messages in large numbers.
The Call Center Process Integrator is a JBPM-based framework where the progress of the individual processes can be planned and overseen on a graphic interface. The FIF-UI is based on (and completes the properties of) a built-in open source portal engine. It offers a well-defined interface for the applications running therein, through which these can define their own menu items and necessary page templates. The FIF-BB is based on the Oracle Coherence-based shared cache technology, completing it with the AJAX Push solution with the help of the Icefaces Ajax framework. The applications are entirely based upon the J EE-technology, currently operating on WebLogic 10.3.2 application server.
| |
|
|
|