X

Best Practices from Oracle Development's A‑Team

Extending Oracle Fusion SaaS with OCI - User Interface

Angelo Santagata
Architect

Extending Oracle Fusion SaaS with OCI - User Interface

Overview

When you purchase Oracle Fusion SaaS Applications (aka Fusion SaaS) , it is very common that you will change it in some way. This can be by an extension, adding new functionality, or simply customizing the UI e.g. adding new fields, perhaps triggers or an entire new section following a standard pattern. How you change your SaaS application depends on the features you need and the module you have purchased and sometimes even the functional module. From our experience in the A-Team we see that Customer Experience (CX) applications (e.g. Sales, Eloqua, Service, etc.) tend to have the most user interface extensions whereas ERP customers typically need fewer UI extensions but more integrations. Almost all SaaS customers implements integration with other business systems.

SaaS extensions typically add user interface functionality by adding new features/screens . For example, within the CX Sales module you may love the "Opportunity Screen" but you want extra features such as a button which checks an opportunities "win probability" based perhaps on some external machine learning algorithm. Another example may be a custom screen which checks the opportunities "line items" and identifies any which are in a "controlled release" thus we require a special approval workflow. 

In this article we will explain how one can design, develop and deploy extensions for Fusion SaaS applications by leveraging Oracle's cutting-edge OCI technologies, specifically focusing on serverless and/or cloud-native technologies. This article will also discuss the advantages, and disadvantages, to each approach with the hope that it will help you choose the right technology stack, or deployment architecture, for your requirements.
 

Extension Styles

Extensions to Fusion SaaS usually come in three user interface paradigms or patterns:

  • Embedded Extensions

    In the introduction we introduced an example of adding a button to a UI to initiate an approval process for a controlled release item. The user interface here allows the user to not only initiate the workflow but also see what line items are in this controlled release and perhaps what stage of approval they are in. Because of the complexity of the user interface this is an example of an extension "embedded within" SaaS, here we are extending the SaaS application so that the user seamlessly experiences the extension as part of the SaaS product.


  • Callout/LinkOut extensions

    A "callout", or sometimes called "link out", SaaS Extension pattern is where a SaaS extension is called from Fusion SaaS but the key difference here is that the entire browser UI is replaced with the SaaS extension (ie not within an iFrame or anything similar). A common example could be when calling out to an external supplier as part of a procurement process. The user interface will often change dramatically enough that the user is aware that they have left the Fusion SaaS however some well designed extensions ensure that the UI look and feel remains consistent with Fusion SaaS and the customer is blissfully unaware they are using an extension. Customers often select a punchout approach instead of an embedded approach when they want the extension to be full-screen. However after the user has completed that activity they can then return back to Fusion SaaS and often can use Oracle SaaS "Deep Links" to get back to where they were when they "punched out."


     
  • Standalone SaaS Extensions

    Standalone SaaS Extensions are not embedded within Fusion SaaS or accessed via a link or button from within the SaaS application UI. Instead they are standalone applications where the user is using the same credentials as Fusion SaaS and accessing Oracle SaaS data but without navigating to the SaaS application itself. A simple example of this might be an application which allows an employee the ability to log vacations within HCM SaaS as part of a custom mobile application. The data is queried and stored within SaaS but the user does not need to go into the SaaS application itself online. Another example could be an extension for a sales rep that shows their contacts on a map and perhaps provides an efficient driving route between meetings that day. This extension would be calling Fusion Sales Cloud to get the sales reps opportunity addresses and then using cloud technologies to calculate the efficient route, show a map etc.

 

Oracle Cloud Infrastructure Technologies for Oracle SaaS Extensions

When extending Oracle SaaS we are fortunate that any web user interface technology can be used for the extension itself. When deciding on the web UI framework the developer should consider multiple aspects including their skills, and how the technology options fit with their overall development environment.

Here are some common Oracle technologies we see customers using to extend Fusion SaaS.

 

 

Oracle Visual Builder gains new features - Propel Apps

Visual Builder Studio

Oracle Visual Builder Studio (VBS) is Oracle's preferred tooling for the extension of Fusion SaaS. It is a low-code declarative environment which is also the development environment Oracle Fusion SaaS is using for many new screens, and in the future we will be using more and more VBS. VBS has a small, limited, local database which can be accessed by its developer but the majority of developers access data from REST Services. VBS is quite unique that it is tightly integrated with Fusion Applications and developers need not worry about defining the REST endpoints, the business objects within SaaS are simply presented to the developer as resources they can use.

However not all data displayed in Oracle VBS comes from Fusion SaaS and VBS can consume data from the following sources :

  • Local business objects (Oracle VBS comes with a small DB of 5GB or you can associate it to a Autonomous DB for large scale database deployments)
  • SWAGGER compliant  REST Service
  • An ADF Describe compliant REST Service
  • Business Objects within an associated Fusion SaaS instance
  • Any REST service
    • For this scenario the developer needs to define all the REST endpoints manually by specifying the URL, the method (GET,POST etc) used , security, expecte payloads etc. 

When using the business objects within Fusion SaaS, Oracle VBS takes care of many aspects of development, including  SSO, identity propagation , performance tuning tricks and much more. Ensuring identity propagation is available is vital to ensuring that the data displayed on the app is following data security rules which are defined in Fusion SaaS and is one of the major features of VBS - it does it for you.

Using a declarative user interface VBS generates JavaScript code behind the scenes. This code can be be modified in the designer UI and then subsequently can still be edited declaratively. Some people consider this to be a great advantage over other systems which do not allow you to tweak the code generated or when the code is modified causes it to not render in the UI. VBS also has the advantage that the majority of the runtime is in the client browser and (assuming the token relay functionality is used - see this blog for more details) all of the REST calls from VBS to the SaaS server go directly from the browser to the SaaS Server not via a middle tier proxy.  If the data source is not on a server which is CORS (Cross Origin Resource Sharing) compliant then the REST call can go via the VBS server through a proxy , this ensures all REST services are consumable by VBS.

Implementing Business Logic

VBS has a number of options when it comes to implementing business logic:

  • You can code it declaratively using "action chains" within the VBS designer. This is a drag-and-drop environment where the resulting "logic" runs in the browser and then interacts with the data sources or other business logic..
  • You can code it using JavaScript in the browser, ideal for UI-based logic or for orchestrating a number of REST calls.
  • You can code it server side using Groovy, which can also be called from the browser.
  • Business objects within VBS can use Groovy lifecycle triggers to implement business logic (for example, the onUpdate trigger, the onRemove trigger, etc.).
    • If you are extending an Fusion Application that supports App Composer then you will almost certainly be using custom objects in App Composer and coding business logic using Groovy code there instead of using the local business objects. The major advantage here is that the business objects can be used in OTBI/BIP reports with great ease.
  • You can use a cloud-native middle tier for your business logic.
    • There are times when you will want to deploy some business logic to a middle tier and not VBS or Fusion because Groovy is not the right language for the business logic. Or perhaps the business logic is shared amongst lots of applications and you all want to use a single business logic tier. 

Advantages of VBS When Extending SaaS

  • JavaScript-based runtime framework
  • Out of the Box (OOTB) Pre-configured Single Sign-On support, and identity propagation, with Fusion SaaS. 
    • Calls from VBS to the associated Fusion SaaS REST services automatically propagate the VBS user to the API call
  • Majority of VBS runs in the browser
  • REST calls to Fusion SaaS can go direct to the datasource (e.g. SaaS) or optionally via the VBS runtime for non CORS compliant services
    • Note : A maximum of six concurrent REST calls can be executed in the browser, this is a HTTP1.1 limitation
  • VBS Applications can run without the VBS runtime and have full access to browsers' offline data sources. This means it is possible to create offline VBS applications which interact with Fusion SaaS, however when working this way a number of VBS features are not available or have to be coded by hand
  • Native/hybrid mobile applications supported using Progressive Web Applications(PWA)
  • VBS uses the Oracle JET framework, which is the same framework Fusion SaaS uses for many screens and thus the UI , behaviour and look and feel is consistent
  • VBS REST runtime is tightly coupled with Fusion SaaS REST Services and performs runtime REST optimization depending on the REST call.
    • For example, when querying the opportunity service and only displaying the OptyID and Name, then VBS REST runtime will automatically add the corresponding "fields=" parameters to restrict the dataset returned and dramatically increase performance.
    • Another example is pagination; VBS is aware of the pagination mechanism used by Fusion SaaS and automatically supports this in its pre-configured data access mechanisms.

Disadvantages

  • Experience has shown us that VBS developers often end up writing JavaScript, thus JavaScript coding skills is probably a requirement for maximum utility.
  • The only JavaScript UI framework supported with VBS is the Oracle JET framework, it is not possible to use other frameworks such as ReactJS, AngularJS etc within a VBS application (apparently the lifecycles don't play nice)
  • The native VBS database is limited to 5Gb of data and no SQL is allowed.
    • It is however possible to associated VBS with a Autonomous Transaction processing database, which therefore overcomes the limitation of no SQL access.

 

 

Oracle Application Express 5.0 New Features

Oracle APEX

Oracle Application Express, or APEX, is Oracle's low-code development environment which has been in development since 2000 (see wikipedia article for a brief history of APEX). It comes free of charge with the Oracle Database and is also available as a managed cloud service where the developer sacrifices some full database access for the benefit of Oracle managing the entire service. APEX is a declarative drag-and-drop development environment ideally suited for displaying and interacting with data stored within its database. If your SaaS extensions primary data store is  within a PaaS Oracle Database then this could be a good choice. APEX can make REST API calls to Fusion SaaS.

Whilst the development environment is drag-and-drop declarative style, APEX does allow you to write business logic in the native database language, PLSQL.

Identity Propagation

For executing REST calls back to Fusion SaaS you will need to authenticate with an application integration ID, this is because APEX does not support out of the box identity propagation. For many customers this is not an issue because most of the interactions are with data in the Oracle Database however if you do need to retrieve data from Fusion SaaS you will likely need to reimplement data security within the APEX application itself as you cannot rely on Fusion SaaS data security. This would also be true for any other technology where you use an application ID instead application identity propagation.

It is possible to integrate Oracle APEX with Fusion SaaS SSO via an Oracle Identity Cloud Service instance that is federated with Fusion SaaS . See this blog article for further details: https://www.ateam-oracle.com/integrating-sso-between-apex-cloud-and-identity-cloud-service-the-easy-way.

Advantages

  • Declarative low code development environment
  • Displaying data from an Oracle database is very easy
  • Ideal for customers who have used previous Oracle development products such as Oracle Developer  (e.g. Oracle Forms), WebDB, etc. and uses PL/SQL as its programming language
  • Free of charge with an Oracle Database License and there is a standalone Oracle APEX Service available
  • The runtime UI can be customized with the out of the box declarative tooling and if needed you can use their own choice of JavaScript framework (e.g. ReactJS, Angular etc) to produce complex user interfaces

Disadvantages

  • Development environment not JavaScript based
  • No native/hybrid mobile runtime available, APEX applications are true web applications and thus you need to be connected at all times
  • Single Sign On with Fusion SaaS is not pre-configured - manual configuration steps will be required
  • Identity propagation from APEX to SaaS is not pre-configured

  • The default runtime user interface, and behaviour, is  different to Fusion SaaS and thus will feel different. This can however be addressed using custom CSS style classes within APEX itself

  • All REST calls start from the database to the service and not from the browser. Having REST calls go from the browser is more efficient and desirable for performance reasons.

 

 

Custom HTML Framework: The Bring Your Own UI Framework Option

"Bring your own UI framework" is another alternative for Oracle SaaS application extensions. There is nothing stopping a SaaS customer from creating additional screens using their favorite UI framework, such as Oracle JET, ReactJS, Angular, Ionic, etc and then embedding these screens within SaaS or running  them standalone.

This approach is however a DIY solution, the developer will need to provide services (like an OCI based webserver) to host the HTML5 artifacts (e.g. html,javascript,css etc) and then code/configure identity management integration with Oracle Identity Cloud Service so that you have some level of single sign on and identity propagation. 

To Middle Tier Or Not

Many customers build applications that directly interface with Fusion SaaS with good results. Oracle CX Sales for example provides a very rich REST API, complete with data security based on the logged in user. Given browsers typically allow 6 concurrent web queries its not too hard to build efficient, performant user interfaces directly against the CX Sales APIs (and other Fusion SaaS REST APIs). However there are often instances when the payload is not returned in the right format and that's when a middle tier may be needed

Several key considerations factor into your decision whether to use a middle tier : 

  • Does the REST (SaaS or otherwise) service you are extending expose a REST API you can easily consume?

  • Does the REST API meet your needs or do you  need to enrich the data?

  • Does the REST API support data security so that if a user bypassed the web UI no harm would be done as the data security is in the service?

  • If you need to execute more than one REST call, can they be done in parallel or do you need to do them in sequence? 

  • Is it OK if users have full access to the SaaS API (from a security/data point of view)?

If you answer “no” to any of the above questions, then you are likely to need a middle tier.

Benefits Of A Middle Tier

A middle tier can provide many benefits, here are some

  • Separation of developer concerns
  • Aggregation of service calls from multiple data sources and respond with one , efficiently shaped payload

  • Can increase performance by aggregating REST calls and calling them from the server, especially when multiple calls each depend on the result of each other
  • Improved performance by caching data
  • Can contain the business logic , making the user interface lighter
  • Encapsulation of the SaaS APIs ensuring that only specific APIs are executed

  • Efficient return payloads by reducing the impact of POST "return values" from Fusion SaaS services. When you update an object, Fusion SaaS will by default return the entire object as a response payload. This is so you can utilise generated key values (like the order id) in subsequent calls. Fusion SaaS allows the option to return nothing, just success/fail, or everything. Using a middle tier you have the ability to reduce the size of this payload to the client and only return what is actually needed.

Separation of Developer Concerns

By using a middle tier, you have the ability to separate a number of concerns between developers. A middle tier establishes a contract between the Web UI (VBS) and the middle tier, and likewise between the middle tier and the SaaS service.

  • SaaS APIs can change and evolve over time. By having a middle tier you can separate the mechanisms that interact with the SaaS API from the UI, so that the UI itself doesn’t need to be repeatedly changed or redeployed. This helps developers develop their APIs while working with a backend data service which may change.

    Consider this scenario:

       A particular service does not currently support a REST API but does support a bulk export mechanism. We know REST APIs are on the roadmap, but we’re not sure when they'll be available. By using a middle tier we can get the UI (VBS) to adhere to an interface and the implementation of the interface (the middle tier) can change when the backend service becomes available.
     

  • Many middle tiers (for example, API Cloud Service and Oracle Mobile Hub) allow the developer to define an API and then provide “mock” data. This allows the web developer to quickly create screens before the middle tier developers have completely built the API layer. Parallel development therefore allows multiple teams to work concurrently in an agile way.

 

Increase Performance BY Aggregating REST Calls In The Middle Tier

VBS applications rely on REST calls to the server to get their data. A single screen can often query 10 or more separate REST calls to get its data, so there can be many rapid sequential calls initiated by the client browser. If your calls are mutually independent (that is, each call doesn't rely on another call's results before it can be made) then you can run them all in parallel and then wait for all of the responses to return. For VBS this is very efficient because you can use the inbuilt parallel flow within action chains to query the data, up to a point. Most browsers enforce a limit on the number of concurrent REST calls which can be invoked by client side JavaScript; currently this number is between 6-8 for modern browsers. When the limit is reached the remaining REST calls are then queued up even though you intended to make all of the calls in parallel.

If you need to execute more than six concurrent REST calls, or if you have REST calls which depend on the results of a previous REST calls, then running these all from a middle tier server can yield performance improvements. For example:

Your user interface needs to place an order. When placing the order, the business logic dictates that you need to validate the stock is available for each product by using a live call to a service, determine if the location of the stock for each product is suitable (based on the previous call), and then place the order for all of the products. For a large invoice this transaction could involve many chains of sequential REST call-result-call-result sequences, each chain running in parallel.

Executing these multiple calls from the client will mean the requests are queued up and waiting for the response for each call. Coding a server-side middle tier API, which accepts the basic parameters and then executes the calls in the correct order to the SaaS server will likely yield higher performance. The server can then return a single response to the client, which in turn is more efficient. An additional advantage of this approach is you are likely to create an API endpoint which exposes a specific API mapped closely to the UI needs, instead of exposing the SaaS application's API which is generic.

Increasing performance by caching data

You can use middle tiers to implement a server-side cache for commonly queried data from SaaS. This cache can reside with the code (a JavaScript object or Java static HashMap) or you could use a different cache layer such as Redis or Memcached to cache your data. In this scenario when executing the REST API to query for data, the middle tier can check to see if the data is already in the cache and if not then query the data from the SaaS Service. The code would then also put newly-queried data in the cache so that any subsequent calls would use the cached data. Querying from the cache will always be much quicker than querying  SaaS applications directly.

This technique is very useful for data which doesn’t change often e,g.“value lists”, list of departments, validation data etc and general standing data such as Product Names, Descriptions, and so forth. If you do decide to implement a server-side cache then you also need to consider how you keep the cache “fresh” and when to invalidate stale data. The specific cache technology you use will also factor into how you manage the cache.

Contain Business Logic

It is almost always a best practice not to have any business logic in the UI , and this is especially true for HTML5 applications , like VBS or JET. By creating a middle tier API for your VBS application you can push all this business logic into one secure place on the server and only expose an API which can be called by the UI. This pattern adds considerable additional security compared to exposing generic SaaS APIs to the client. Validation logic however is acceptable, and recommended, on the client side to provide validation which prevents invalid data from being sent to the server. Worth noting that the same validation logic must also be implemented on the server

For example:

In a VBS application a user is able to place an order for a stock item. Depending on the size of the order, the location of the stock will determine which shipping service to use for the delivery of the item. This logic could be performed on the client side using a VBS “Action Chain,” but it's better to perform it on the server side in the middle tier. Coding the logic there would ensure the rules are always adhered to and additionally since the calls may require additional calls to validate the  the , performance will almost certainly be better.

Front-End the SaaS APIs

Sometimes the SaaS applications' APIs are not suitable to be exposed to web clients, or the internet at large. For example some APIs don’t support data security to the level required in the app or the returned data format is not formatted in a way that is easy for a web client such as VBS to consume. Responses from these APIs will likely require some data manipulation code and putting that data manipulation code into a middle-tier will often be more desirable, for both performance and the reduction of client side code complexity. All the composition, filtering and merging of data can be done server-side and then transferred to the client in an optimized format, specifically tailored for client which in turn leads to simpler client code.

Reduce Impact of POST Return Values From Fusion SaaS -Based SaaS services

With Fusion SaaS based Oracle SaaS applications when you invoke a POST, or a patch, to update a value in the database, the application's API will by default respond with the resulting entire object as a response payload. This is intended for you to be able to use the payload for subsequent processing (such as obtaining the primary key). Without a middle tier, this network traffic goes back to the client and when scaled up, the impact could be larger than one expects. There is a parameter you can put on the API Call (link) where you can tell the API not to return anything but a 200 code to indicate the call worked. While this works for some use cases, it is not suitable for many others especially when a value in the payload is required.

By using a middle tier, you can receive the full payload server side and create a custom payload for the client only sending back precisely what is needed. The heaviest data transfer is contained server side where the network is fast and abundant.

Choosing A Middle Tier

If you decide to host a middle tier for your Oracle SaaS application extension you'll need to decide which product/service to use. There are several factors that influence the decision, including developer experience with a particular product or language. Given VBS supports REST calls and most middle tiers support REST services it might seem that any middle tier choice is viable, but sometimes one choice is superior to others.

For example, you may benefit from a middle tier that is able to accept security tokens and check their authenticity with Oracle Identity Cloud Service, in this case a middle tier option that offers that functionality "pre-configured" might be a better choice.

At Oracle there are number of middle tiers available, here are some of the most popular choices :

  • Oracle Helidon
  • Oracle Functions
  • Oracle WebLogic Server

Oracle Helidon

For developers who prefer to use Java, Oracle Helidon is an ideal option for building REST services . Helidon is an open source set of libraries actively curated by Oracle and contain a number of features which make it an ideal choice for an Oracle middle tier.  For production runtimes Oracle recommends running Helidon as a container within the Oracle Kubernetes Engine.

You can review the complete list of Helidon features at the Helidon website. A notable feature for SaaS extension applications is the support for the the Open ID Connect provider (also called the OIDC Provider security provider) which allows you to do SSO and identity propagation with Fusion SaaS. See https://helidon.io/docs/v2/#/mp/security/02_providers) for more information.

When using Oracle VBS and the OIDC Provider you can :

  • Create a client confidential application in your Fusion SaaS Associated IDCS instance
  • Add the Fusion SaaS applications resource to this application 
  • Add the OAuth confidential application to a VBCS service
  • When calling the REST Service, VBS will now automatically add a OAuth token header
  • Helidon will automatically authenticate the user based on the token and set the user principal within the Helidon Application

For more information on how to setup this up see this blog article https://www.ateam-oracle.com/developing-saas-extensions-using-vbcs-and-helidon-uservices-part-1

Advantages

  • Helidon is small and fast, supports the MicroProfile SE and MP. Specifically the MP feature allows for easy transition for developers familiar with Java Enterprise Edition coding, JAX-RS etc.
  • Helidon supports GraalVM, an incredibly performant Java runtime.
  • If you run Helidon within Oracle Kubernetes then the service mesh, routing, and so on is all effectively serverless (Oracle manages the infrastructure) you just deploy your container

Disadvantages

  • Not really serverless you still need to maintain your container
  • Java-based coding set of libraries

Oracle Functions

Oracle Cloud Functions is Oracle's answer to the need for serverless functions. With Oracle Functions you can write your code in a variety of different languages (such as Java, Python, Go, and more), deploy the functions to the cloud, and then call them in a serverless way. Oracle manages the entire runtime stack, you only provide the code you want running at that time.

Oracle Cloud Functions however are not security-aware, nor are they REST services. To provide security and REST functionality you need to add an API Gateway to the architecture :

To REST enable cloud functions you will need to add API Gateway to fulfil the following functionality : 

  • Map REST Service URLs, and methods, to Cloud Functions
  • Authenticate REST requests as they come in 

API Gateway can be configured much the same way as Helidon can with an OpenID Connect OAuth application defined in Oracle Identity Cloud Service. For more information on how this can be setup please see this blog https://www.ateam-oracle.com/the-cloud-native-approach-to-extending-your-saas-applications and sample code https://github.com/oracle/cloud-asset-fusion-serverless-vbcs-sample

Advantages

  • Truly serverless architecture, the customer doesn't need to manage anything 
  • Use your preferred programming language
  • Very low cost, zero cost when the service is not being used

Disadvantages

  • Very limited routing infrastructure options available
  • Cold starts of Functions can be an issue but providing the functions are used then this tends to be less of an issue
  • Code centric

Oracle WebLogic Cloud

Many customers may already have Oracle WebLogic Server running in the deployment landscape. Oracle WebLogic Server is an excellent choice for deploying some middle tier code, and is a good choice if you need more than just REST Services: for example, you can use message-driven beans, EJBs, etc. However, Oracle WebLogic Server should only be used if you need the additional features i brings (e.g. full JEE functionality) or already have it running in your deployment landscape. Oracle WebLogic Server can now also be deployed in a Kubernetes cluster to take advantage of Kubernetes service mesh features, for more information please see this GitHub repository: https://oracle.github.io/weblogic-kubernetes-operator/userguide/introduction/introduction/.

Advantages

  • Full featured Java Enterprise Edition server
  • Established code base and many examples available
  • Compatible with ADF 12c (which is important for some legacy ADF customers)

Disadvantages 

  • Maybe excessive for many customers
  • Not serverless and can be complex to maintain
  • Code centric

Oracle Integration Cloud 

If your middle tier logic tends to be routing logic, simple calculations, and perhaps protocol conversions/transformation (such as SOAP to REST) then another good solution is Oracle Integration Cloud (OIC). OIC is an excellent declarative integration tool. Although designed for integration scenarios (sync and async) it can easily and successfully be used for middle tier business logic. OIC is exceptionally suited to integration-styled middle tier integrations, such as transforming data, transforming protocols (SOAP to REST), and orchestration logic; but it is not well suited when doing synchronous aggregations or very complex business logic (such as sorts, or aggregation of data). For those operations, a 3GL like Java is better. Another area where OIC may not be ideal is around identity authentication and identity propagation of a logged-in VBS user to an extended Fusion SaaS application: this identity authentication integration is not pre-configured with OIC.  For an example of how to use OIC to propagate identity from VBS to Fusion SaaS, see this blog: https://www.ateam-oracle.com/identity-propagation-vbcs-%3E-ic-%3E-fusion-applications.

Advantages

  • Highly productive declarative environment
  • OIC provides a wealth of additional functions, such as logging, alerts, and dashboards
  • Very quick to get started with; many integrations can be set up with zero coding
  • If needed, some coding using JavaScript is possible. See this blog for more details https://blogs.oracle.com/integration/using-a-library-in-oic
  • VBS is often bundled with OIC so it can be very cost efficient to use both together
  • The service is managed and run by oracle 

Disadvantages

  • Using an integration tool as a middle tier has some limitations
  • Not well-suited to very complex business logic that requires many if-then-else statements, loops, etc. 

Summary

The decision of which user interface technology you should use for your SaaS extensions depends on your use case, skills, and preferences. Oracle Visual Builder Service (VBS) is often the best option due to its integration with Fusion SaaS, and the future plans for VBS involve even tighter integration. If your data is primarily stored in an ATP database, then Oracle APEX may be the better choice. You can also provide your own custom or third-party UI if needed. 

Sometimes no middle tier is needed, but in many cases a middle tier is necessary for transformation, business logic, to provide more efficient and faster handling of REST API calls, or to separate developer concerns during development. There are many options for middle tiers, but Oracle customers frequently use Oracle Helidon, Oracle Functions, Oracle WebLogic Server, or Oracle Integration Cloud, depending on their service bundles, types of integration handling needed, and other factors. 

 

Compare and Contrast UI Technology Services/Layers

Product

Disconnected

JavaScript
 

PLSQL

Complete UI control

Ideal for data in DB

 

OOTB SSO and 
Identity propagation

True
low-code

Tight Integration with Fusion SaaS

Local Business
Objects

APEX

NO

NO

YES

YES

YES

 

Yes but not OOTB

YES

NO

YES

VBS

YES

YES

NO

YES

Good

 

YES

Good +JavaScript 

YES

YES

HTML Framework

YES

YES

NO

YES

NO

 

NO

NO

NO

NO

 

Compare and contrast Middle Tiers

Middle Tier

Pre-configured Single Sign On

Support for
Identity Propagation

Declarative 

Code Based

Serverless

Choice of 
Languages

Integrated 
Dashboards

Helidon (on Kubernetes)

YES

YES

NO

YES

NO

NO

NO

Oracle Functions

YES

YES

NO

YES

YES

YES

NO

Oracle WebLogic Server

YES

YES

NO

YES

NO

NO

NO

Oracle Integration Cloud

NO

VIA CODE

YES

NO

YELLOW

NO

YES

Next Steps 

As a team we have written, and still writing!, a number of articles where we cover many of the "Extending Oracle Fusion SaaS with OCI" topics. If you want to learn more navigate to the Extending SaaS with OCI Series post and checkout the other articles we have written. Do let us know if you have any other topics you would like us to cover do let us know!

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha