Oracle Integration Cloud Gen 3 Upgrade - Tips and Features

As some of you may be aware, Oracle is migrating their OIC Platform to its new generation, called OIC 3. For those that remember the Gen 1 to Gen 2 migration, this one is more impactful, delivering a significant overhaul from a UI and usability perspective, as well as many new features. This entry will cover some of the features that I am most excited about, as well as important links and other key information relative to the upgrade effort.

An overview of key highlights with opportunities is below, and detailed documentation to all new features and other information is available at the bottom via links. Also, new updates are being rolled out to OIC Gen3 every month.

Gen3 Feature Highlights	Opportunities
Large payload support for integrations	Payload support is growing with Gen3, which allows for more complex use cases and larger volume to be processed, which will be a win already, but also can eventually lead you to rationalizing other tools away, such as MuleSoft and Biztalk, if you use those platforms.
Enhanced Disaster Recovery Capabilities	Gen3 will have an enhanced Oracle Managed DR offering that should simplify and reduce manual labor versus our existing DR strategy in Gen2, more on that below.
Private Endpoint Connectivity	This feature will set the stage to deprecate the connectivity agent used in OIC to connect to the DBCS or ADB (autonomous database) where you may house PLSQL for complex business logic, and instead allows us to connect OIC to the Autonomous Database directly, and if you have your own tenant ADB for VBCS, then both can coexist. In short, you can rationalize databases by removing the DBCS environments and consolidate VBCS and OIC into a single ATP (autonomous database), and while replacing the connectivity agent (third party) with an adapter (native), reducing technical debt and failure points, should you have this type of configuration in OIC 2 currently.
New recipes and adapters	Enhanced connectivity and opportunities both to accelerate development of new integrations and to reduce technical debt, such as custom integrations between OIC and custom identity or token providers.
Enhanced Event Framework	True pub sub capabilities will now exist in OIC, which will simplify when we use this pattern, as today we have to write parent/child integrations with custom hand offs, versus using native event capabilities internally in OIC. There also appear to be enhanced polling capabilities.
RBAC and Projects	This feature will enhance how you utilize global OIC environments across business units and teams, better allowing HR and AFT to co-exist on the same environment (for example), reducing risk and improving supportability. You can also move away from having independent Dev environments for HR and AFT or CX, and consolidate.
RPA Capability	RPA capabilities will be added to OIC, which will allow for the utilization of this feature to address RPA requirements and aid in removing dependencies with external tools and the utilization of less integrated and supported RPA capabilities, such as Blue Prism, in the context of the broader Oracle footprint.
Increased Observability	Changes to monitoring and API framework that will allow for enhanced monitoring capabilities.

To note:

• Not all features in Gen2 may yet be available in Gen3, and this upgrade also impacts VBCS and Process Automation, so extensive testing will be required, including performance testing.
• Oracle has mentioned that middle of next year will be the deadline to migrate, potentially August, and although initial research shows that many clients are still in Gen2 and that upgrade issues can happen, you should plan and execute this sooner than later.
• Some of our features weren’t ready or fully developed in OIC 3, such as the VBCS auto upgrade, and other features, and also that there’s several break/fixes that have been completed to stabilize OIC 3. As an example, Oracle was tracking an internal bug relative to stage files read/write, and this had a performance difference compared to Gen2, as an example 20-minute runtimes would go to an hour or two, which highlights A) the need to check the Known issues link, but B) to perform extensive regression testing, and also performance testing.
• I also recommend that you upgrade a single instance as a pilot, perform your test plans there, prior to moving to upgrading several environments at once.
• The VBCS and PCS assets within your Gen 2 instance will now be part of the auto upgrade process, which was previously not available, and would have caused significant manual work on your end, however, there's some outstanding licensing concerns Oracle is working through in this regard and some updates have been postponed until February, but if you have a simple instance without VBCS or PCS, there's no reason to wait, and you can go to OIC 3 already.
• Oracle utilized the auto upgrade process to internally upgrade many of their complex OIC assets in Q4 (which include VBCS and PCS), which has increased confidence in the process for those that will undertake the complex upgrade path.
• We confirmed that the IDCS stripe that the Gen2 instance is related to will not be impacted by the upgrade, and that OIC instance names, URL’s, etc. will also not be impacted.
• We confirmed the connectivity agent does have changes relative to how it authenticates (no longer supports basic authentication), but that it should be seamless during the upgrade process, but if you use a connectivity agent make sure to test it well.
• When you login to your Gen 2 environment, there will be a section that tells you if your environment meets the prerequisites to be upgraded, it is important these upgrade pre-checks pass, check the link below for more information. Also, if you don't want your environments to be auto upgraded if the pre-checks are met, it's important that you communicate with Oracle, to avoid surprises, you can raise an SR to postpone migrations.
• Lastly, our current understanding is that the deadline to migrate to OIC 3 will be August of 2024, currently, but this could move depending on adoption and issues.

Links to Documentation:

• What’s New in Gen3: Oracle Cloud What's New for Oracle Integration 3
• Differences between Gen2 and Gen3: https://docs.oracle.com/en/cloud/paas/application-integration/whats-new/index.html#GUID-6366FC51-5836-4D2E-AF8E-E9E939BF7330
• FAQ: https://docs.oracle.com/en/cloud/paas/application-integration/oracle-integration-oci/upgrade-faqs.html [docs.oracle.com]
• Upgrade pre-checks: https://docs.oracle.com/en/cloud/paas/application-integration/oracle-integration-oci/prepare-upgrade-oracle-integration-3.html [docs.oracle.com]
• Known issues: https://docs.oracle.com/en/cloud/paas/application-integration/known-issues/preface.html#GUID-34683717-9FA8-4982-BD27-39E1AAA43FBF
• Upgrade from OIC Gen2 to Oracle Integration 3 (OIC3) - Schedule Information (Doc ID 2977663.1)

Oracle FA - Credential Store Framework (CSF) Key Registration with Oracle Integration Cloud for Business Events

The purpose of this entry is to provide information regarding registering CSF keys and configuring connectivity between the Fusion based ERP application and Oracle OIC!

As discussed in prior entries, Cloud ERP provides business events which can be subscribed to by Oracle Integration. To enable the trust between OIC and ERP, in a FA-based SaaS instance, the outbound call of a webservice uses a OWSM security policy which retrieves the credentials for the call from a CSF Key.

Credential Store Framework (CSF) keys are credentials that use basic authentication (username and password) to certify the access of users and system components. Once the registration process is completed then the CSF keys will help to trigger the business events and call-backs from ERP to OIC, and after catching the event in OIC, we can apply our business logic and perform any other action, such as calling an external API, sending an email, writing the output to a database, and more.

For this to work we must create a local IDCS account with admin privileges in OIC, and use that ID in the CSF key configuration. We must note that Oracle now also has a token based alternative, but that will be covered in another entry.

To generate the CSF key, follow the below steps:

a. Login into the OIC instance with the user credentials and navigate to the Integration home page.

b. Click on the username from the top right corner of the OIC page and select About.

c. The CSF Key will be generated by appending the identity domain and OIC admin. The format for the csf key generation is mentioned in the below table.

Format: <Identity Domain><Service Instance>

Now, follow the step by step process to configure CSF key:

a. Navigate to Oracle ERP SOA Composer to configure CSF key from the below mentioned url.

b. SOA Composer URL - https://<erphostname>/soa/composer

c. Login to the cloud application with your Oracle Cloud ERP user credentials

Note that you will need the following two roles, to perform the following actions:

SOA_OPERATOR_ROLE_JOB

SOA_DESIGNER_ROLE_JOB

d. Once the login is successful then click on the Manage Security from the right side of the page. Then click on the Manage Security and another popup will be open to provide the Manage Credentials details. Please refer to the below table to provide the Manage Credentials details.

Once the details are provided then click on the Register button to complete configuring the CSF KEY.

#	Element	Description	value
1	csf-key	Specify the csf key as extracted from the section before.	<Identity Domain><Service Instance>
2	User Name	Enter the OIC admin user name	Local account we talked about earlier.
3	Password	Enter the password for accessing OIC application	<PASSWORD>
4	Confirm Password	Renter the same password for second time	<PASSWORD>

Now it's time to verify the configuration has been done successfully.

Once the CSF Key configuration is completed then the CSF Key verification should be done.

a. Access the below mentioned FA Cloud instance by executing the following URL in a browser.

NOTE – Access the Event Subscription URL from IE, Firefox or Edge Browsers. Do not use Google Chrome browser

 
b. Event Subscription URL – https://<erphostname>/ soa-infra/PublicEvent/subscriptions

If the event subscription url doesn’t work from the browser, then use the same URL in Postman to test it.

In the basic authentication section in Postman, pass the credentials for the local user and run the endpoint.

With this, OIC will now be able to listen to business events from ERP. One additional point to note, if you ever change the password for the account used for this setup, this trust will be broken. Also, rather than using the "update" option when changing the password and following these steps, you have to "register" again, because the changes won't take effect due to caching.

API Gateways, and Oracle FA, with Examples!

API Gateways have gotten increased exposure over the past few years, as SaaS offerings from major vendors continue to accelerate in usage. SaaS in general provides many benefits to customers, but it does present several challenges relative to integrations and extensions, as you are restricted to public API's provided by the vendor, or native file loading capabilities, if you want to perform inbound and outbound data movement of any kind.

In Oracle FA specifically, the necessity of utilizing the API framework for your real time or near real time needs is paramount, and Oracle does a good job of documenting their API capabilities, which can be seen here for Financials, and just with a few clicks you can browse API support for other FA offerings.

Now, an API Gateway provides a layer between the caller and the target, let's say Oracle FA, where in you can perform several actions that will greatly benefit you at scale. With an API Gateway you get some of the following benefits, which are summarized in the graphic below in bullet #1, also, #2 talks to some of the capabilities that you would not want to perform in the gateway, and instead utilize a middleware tool for.

Let's take Oracle ERP as an example, and let's say you want to publish AP related API's to certain consumers but you want to distinguish the traffic generated among them, and you want to protect ERP from abuse. With the gateway you can create quota policies that will limit the usage of the consumer of the API that is proxied in the gateway, and after the user has utilized their quota, their access will be revoked. Similarly, you can create spike arrest policies that will prevent abnormal behavior from taking place, in the way of excessive amount of calls from a consumer that typically does not have that kind of volume. You can also create security policies that inspect incoming request payloads and look for malicious code, in the proxy execution flow, before the message can damage the target. In terms of usage metrics, you can direct results from the API interactions to an Enterprise Logging tool, such as Splunk, where you can build dashboards that will give you in depth analytics about who is making which calls, and what the errors are, etc. so you can discover trends and proactively resolve issues, and you will not be able to do this by just allowing users to call API's in FA directly, and troubleshooting will be labor intensive.

Let's discuss another use case, around simplifying consumer experience of your services. In ERP, oftentimes you need internal ID's from multiple API call's to ultimately perform an action, or just executing API's in sequence. Examples of this can be creating an AR Invoice for a new customer, creating a new customer, or creating a supplier, where multiple API calls have to be made in sequence to accomplish the task. In order to simplify the process and create developer friendly APIs, you can utilize your gateway to create API chains, where you can create a consolidated proxy endpoint with all the payload elements that the consumer will need to pass, and they can make that one call to create a new supplier, and your gateway will then orchestrate the chain of events to create the header, sites, addresses, locations, etc. without burdening the consumer who likely doesn't understand Oracle ERP. You can also hide away the complexity from the Gateway entirely, and proxy an application driven integration from OIC in the gateway instead (or another middleware), as shown in the below example, this is very useful if the actions in the gateway would require significant business logic or complexities beyond what is recommend as far as Gateway scope (see first graphic). Additionally, you can drive reusability and speed up adoption since consumers will just need to meet your payload requirements and understand their own data, and not build significant technical debt or have significant knowledge of Oracle ERP technically.

The above is exemplified in the following graphic, where the Apigee API Gateway is utilized to hide away the complexity of creating a Customer from the consumer. Here the consumer calls the gateway with a consolidated payload, and the gateway invokes OIC where the various API calls to accomplish the task are performed, without the consumer needing to take on this complexity.

Click on the image to expand it!

Lastly, in terms of options, Oracle has an API Gateway offering that integrates very well with FA and also the Oracle Integration Cloud, and if you don't have an enterprise wide gateway that you are required to use, this will be your best option, you can read more about it here. However, if you have your own gateway and want to use it to enhance FA in ways similar to those described here, then you can certainly proxy your API's in your gateway of choice, and you will just need to integrate your Gateway with Oracle IDCS to securely do auth with FA, unless you are willing to store basic authentication details in your gateway and bypass IDCS (which is not recommended).

Elaborating Security Requirements

In recent years, including due to the pandemic, there has been more attention brought upon IT security as a practice. Across the technology industry, the business has increased the IT security budget tremendously as a result, resulting in large security organizations being created, which actually even operate independently from the technology organization overall, in many ways. However, although the dollars and focus have shifted to increment the security posture to react to the growth of cyber threats as the digital footprint of most companies has expanded, it can be said that security it's still not being integrated very well into large software projects, particularly during the requirements gathering phase.

Checkout the full article regarding this topic over @ Linkedin https://www.linkedin.com/pulse/elaborating-security-requirements-julio-lois

Cloud Security – A Reflection

The Gartner article by Jae Heiser, Analyze the Risk Dimensions of Cloud and SaaS Computing, was really relevant for me in the topic of Cloud security and the different implications of IaaS, PaaS and SaaS models from a risk management perspective. As more vendors move their solutions to the Cloud, forcing customers to adopt some sort of Cloud model, we are left struggling to figure out how security looks; it is certainly one of the toughest things to deal with in this space.

Heiser correctly points out that analyzing risks, when it comes to cloud computing, becomes complex given a lack of best practices on the method and content of a cloud services risk assessment. This is driven by the lack of transparency presented by service provides, particularly in a SaaS model. Under normal circumstances, where the organization has control, there is an expectation that the systems that are being evaluated are well proven and well understood, meaning we know where all the layers are located and privileged users are identifiable and supervised in many ways. When it comes to SaaS solutions, the system administrators are not known and many different layers of the architecture, like the services, network, the storage, the servers, and in many ways even the application, are black boxes, as far as the client is concerned. As Heiser notes, this concern is not so prevalent with an IaaS model, given customers control a lot more in terms of the data, the application, the virtual machines and they are actually responsible for monitoring and auditing to a large extent, and have the required access to perform such activities. Lastly, with PaaS, there is far more shared responsibility between the customer and the provider given where the security controls are located.

Again, with SaaS, the provider is responsible for pretty much all of the security functionality, the monitoring, and incident response. All this means is that you as a customer have minimal ability to add controls and other security mechanisms outside of functionality that is native to the application, as Heiser notes. Do you want to set up a custom alert when a financial period is opened or a user creates an invoice over a specified threshold? You better hope the application can do that out of the box, because you can’t extend it. Also with SaaS, design and build of any application related functionality is a black box for customers, and you may simply receive and email with the latest updates that will be released for your application the following month. Without this transparency there can be no expectation that functionality will remain the same, meaning we have to take into account security testing in the time allotted to us as users, in order to test whatever controls we do have access to before the updates get rolled out to your Production environment.

One important point Heiser talks about, which many don’t think about, is that often times your cloud providers are themselves a customer of an additional provider. So basically, your provider may own and support the application, but they may be using another provider for the infrastructure, the storage, etc. This is called a nested hosting arrangement, and it really complicates security even further. Everything that has been mentioned to this point has really been assuming that your SaaS application is fully supported by one vendor, but the risks are compounded, and the complexity increases many times over, when nested hosting is in place. Basically, you need to conduct a risk assessment of each and every provider involved in each layer of that cloud application (this may apply to more than just SaaS).

As Heiser reinforces, oftentimes there’s really nothing you can do given the lack of transparency in many areas, so you have to rely on your contract serving as a mechanism that ensures appropriate levels of security and service level expectations, at the risk of transparency and real control. This of course is all depending upon whether the legal system will enforce penalties for noncompliance and to what degree. Overall, it is very clear that security in the cloud is a behemoth of a problem, and it involves everything from risk assessment of your providers to controls, to auditing, to monitoring, and everything you can think of that’s security related and you were able to do in your On-Prem environments. It is worth noting that many vendors will work with you and provide evidence of whatever controls you ask of them, and you should, and they should be able to produce proof, also, certain providers have different tools that handle security within their suite of Cloud tools, which you can leverage to satisfy some additional controls.

References

Heiser, Jay. Analyze the Risk Dimensions of Cloud and SaaS Computing. Gartner. March 15^th, 2013.

Java Web Start for Oracle EBS

Hello Everyone,

I have been exploring options in regards to our dependency on Internet Explorer (slow and clunky) due to the fact that we rely on the Java Plug-in (NPAPI) to launch the EBS Forms, and IE is the last reliable browser to support the Netscape Plug-in Application Programming Interface (NPAPI), which limits our users to only utilize this browser. Additionally, Microsoft continues to slowly but surely phase out IE in favor of Edge.

Those used to be our only problems, Oracle planned to deprecate the Java Plug-in for web browsers starting with the release of Java SE 9 (and they have).

The solution that Oracle is now offering in regards to these problems is Java Web Start. Java Web Start applications can be launched independently of a browser since they do not rely on a browser plug-in, and it provides a migration path from Java applets.

Below is a snippet of the architectural differences between the NPAPI approach and the Java Web Start approach:

The below is a snippet from Oracle in regards to Java Web Start:

What is Java Web Start?

Java Web Start provides a browser-independent architecture for deploying Java 2 technology-based applications to the client desktop. With Java Web Start, users can launch a Java application by clicking a link in a web page. The link points to a Java Network Launch Protocol (JNLP) file, which instructs Java Web Start software to download, cache, and run the application. This way, users can download and launch applications without going through additional installation procedures.

Java Web Start software is installed as part of the Java Runtime Environment (JRE) software. Users do not have to install Java Web Start software separately or perform additional tasks to use Java Web Start applications.

What will this help solve?

1. Oracle, and modern browsers, will soon (already have) stop supporting NPAPI and launching Oracle Forms as we do today will not be possible (without major security concerns).
2. Many On-Prem EBS shops have issues today keeping up with JRE versions, and continue to use JRE 6 or 7, due to complexities around signing JAR files and the JRE executable (and compatibility issues with customizations).
3. Internal security guidance at most companies is aggressively moving to being more up to date with JRE versions on workstations, and Java Web Start is less dependent on the JRE and Oracle is working hard on ensuring the latest versions of JRE support Java Web Start.
4. Users can again utilize their preferred browser to navigate Oracle EBS Forms (such as Chrome, Firefox and Edge), and will no longer be limited to Internet Explorer.

In terms of implementation, if you are still on SSL, I believe you should combine these initiatives (Webstart and TLS migration) given you will also need to perform Forms testing when implementing TLS due to certain pre-requisite patches, and some tech-stack prerequisites are shared.

These are not nice to haves, this is the guidance from Oracle in terms of where they are moving with Forms and browser security. I believe the sooner you take these on the better, both of these are recommendations/mandates from Oracle noted in the Quarterly EBS Upgrade Recommendations: July 2018 Edition (and previous editions going back to 2017, however, they weren’t very mature).

I recommend you do a POC of the Java Web Start component by applying the pre-requisite patches in a test environment to test functionality and some key custom forms (which Oracle says should be fully supported by switching from NPAPI to Java Web Start).

Below are some key documents around Java Web Start (which is now fully supported for Oracle E-Business Suite Releases 12.2 and 12.1):

Using Java Web Start with Oracle E-Business Suite (Doc ID 2188898.1)

https://blogs.oracle.com/stevenchan/java-web-start-now-available-for-ebs-121-and-122

https://blogs.oracle.com/stevenchan/e-business-suite-and-java-web-start%3a-frequently-asked-questions

Thanks,
Julio

SSL to TLS, Oracle EBS 12.2

Hello Everyone,

In reviewing the Quarterly EBS Upgrade Recommendations: July 2018 Edition one of the key recommendations is to migrate from SSL to TLS.

12.2 inbound, outbound, and loopback connections are now (as of Q3 2016) certified with TLS 1.2, 1.1, and 1.0 as noted in the below article:

https://blogs.oracle.com/stevenchan/tls-12-certified-with-e-business-suite-122

The below doc ID contains the instructions for the move:

Enabling TLS in Oracle E-Business Suite Release 12.2 (Doc ID 1367293.1)

There is a  workflow patch, in addition to performing the migration work, so there is definitely a lot to do, specially if you are on an older version of the AD & TXK patches and your JDK version is pretty outdated.

The benefits for this are many, including easing the path to making your EBS accessible to external clients and better browser security!

Thanks,

Julio