Comparison of EBS vs Fusion technology solutions
In this article I will try to explain the technological differences between Oracle EBS and Oracle Fusion products.
Oracle eBS – On-Premise
For Oracle eBS, all administrative tasks are performed by local administrators who have extensive technical knowledge of the application. The administrators fully control and select a set of installation corrections. Depending on the patch installation policy, the application and even individual modules may have different update levels. The Oracle eBS application is installed on the infrastructure available within the organization. This means that administrators are responsible for the full technological stack of such an installation. Starting with the disks, network components and the server operating system. It is worth noting here that the application can also be installed on a virtual machine shared as an IAAS service in the Oracle Cloud.
Oracle Fusion – Cloud
Oracle Fusion is provided as a service. This means that application administrators outsource administrative activities to the service provider. Application administrators focus on high-level activities aimed at ensuring business continuity. The application is updated on a quarterly basis. This means that the application is always up to date and the possibility to postpone the installation of updates is limited. Therefore, when planning to implement the solution in the Cloud, it is necessary to be aware of the customer’s need to adapt to the software manufacturer’s planned application upgrades, in particular in terms of testing after the upgrades. The Oracle Fusion application works on the infrastructure of the Oracle software provider. This means that the organization does not have full access to the technical infrastructure on which the application is running. In this model, the service provider is responsible for managing individual elements of the application architecture. The following figure shows a comparison of the division of responsibility for infrastructure elements.
Integration and extensions
Oracle eBS – on-premise
In Oracle eBS application, the programmer has full access to the database, where he creates database objects such as tables, views, and packages that perform particular extension functions. For Oracle eBS, all changes are made directly from the application database. Developers use the available APIs to write their own extensions. The programmer can also create his own data management tools. There is also a mechanism of open interfaces in the application, which the programmer must supply on his own. Oracle eBS application allows to create new screens using such solutions as Oracle Forms or OAF framework – to build WEB elements of the application. Extensions built for Oracle eBS applications are executed on the same database as the application. This approach allows for quick and easy data integration and synchronization between standard application elements and the extension. It is also possible to make some modifications to the user interface operation thanks to the personalization feature in Oracle eBS.
Oracle Fusion – Cloud
Oracle Fusion provides access to the application through a number of integration mechanisms for both downloading and manipulating the data. Neither the developer nor the administrator has access to the database, which makes it necessary to use different integration and extension mechanisms than Oracle eBS. The following REST Service integration methods are used to build extensions and interfaces in the Fusion application – the application is equipped with a number of REST services that allow you to load, update and download data. In some cases it is also possible to delete data.
SOAP services – the application is equipped with a number of SOAP services that allow you to load, update and download data. FBDI – this is a method to import data into the ERPC system using CSV files. This method is used to load large volumes of data. The files are first placed on the file server – UCM and then loaded into the open interface tables, from where they are read into the module. Cloud Connector – this is a tool that allows you to export large volumes of data to a file server – UCM. Using the above tools it is possible to create direct integration with external systems. The implementation methodology usually uses an intermediate layer – the integration platform, which is responsible for message exchange and manages individual elements of the data exchange process.
The following diagram shows the integration diagram for the Fusion application
Oracle Fusion allows you to modify the user interface through Page Composer functionality and Application Composer. This makes it possible to make some modifications to the operation of the user interface. The equivalent of this feature is the ability to customize in Oracle eBS If you need to build a new application screen in Oracle Fusion, use a separate service. For this purpose, you can use the PAAS platform in the form of a database service from APEX or another service that will allow you to create a suitable interface. To some extent, it is also possible to use your own solutions, including the on-premise model. In each of the above cases, it is necessary to integrate the application because from a technical point of view it is a different service on a different machine. Such integration shall be carried out by means of standard elements, as outlined above.
On-premise licenses v. Cloud subscriptions
For licenses purchased in the on-premise model, the customer is entitled to use the application even if the technical support service (ATiK) ceases to be paid to the Oracle software manufacturer. If the customer does not pay ATiK fees, he will only lose the possibility to use the manufacturer’s technical support, i. e. he cannot download any corrections or upgrades to the application. In the case of a subscription purchased, i. e. access to the application in the Cloud model, the client gets access to the application only if he pays the subscription fees. This difference is most important in case the customer would like to stop using the application in production. In the case of Cloud applications, despite the fact that the application will not be used in production by the client, he will be required to pay fees in order to have access to the application in read-only mode.