Its been a busy month when it comes to blogging for the folks at Oracle, as July saw a new quarterly release with new usability improvements and connectors.
Handling integration between Oracle SaaS applications and modules has been something of an evolutionary journey. A couple of years ago if you wanted to intgrate say HCM and ERP you needed to ICS or OIC to perform the integration.
In many respects this wasn’t such a terrible thing. Technically as it meant that the back end database schema development for each app was not going to be slowed by needing to be mutually dependent with each other. As a result avoiding the complexities of managing a canonical model and ensuring any changes to that model are delivered in a manner that aligns across multiple development teams plans.
Although you can see from a marketing position it might not have seemed so great, as the customer incurs more cost and development effort to realize a process of managing people (HCM) and paying them (ERP) for example.
Things have moved on, and as long as SaaS apps reside in a Global Single Instance (GSI) (i.e. same region, account and deployment) then for the major products (e.g. ERP, CX, HCM, etc) are internally integrated so a person change in HCM will propagate to ERP as necessary. This certainly reduces the need for integration, saving effort (and the cost of needing OIC).
The problem now is understanding which entities in the SaaS apps are integrated out the box if you deploy using the GSI manner. If you have been working from an integration/technology view point with ICS and OIC for a while it is very easy to get sucked into thinking you need to repeat the integration. After all explicitly integrating the apps is how we started out.
Oracle also want to make it very easy for non Oracle products to integrate, so OIC documentation and the many very good blogs from product management and the engineering team focus on external integration which does (for me atleast) lead to thinking about the older way of working.
Look to see if you’re working with GSI deployment or not. If it isn’t a GSI setup then the old way of working is required. If it is, then determine whether the entity or processes are out the box integrated. This is probably best approached from the SaaS documentation today.
Plenty of good articles published in the last month …
April has been a relatively quiet month article wise after a couple of bumper months. we’re seeing lots of new content already for May.
|Article / Link||Author||Subject Matter||Connecting|
|Token required to provision an Oracle Integration Cloud instance||Ankur Jain||OIC|
|Why is iPaaS adoption growing to handle integrations in cloud architectures?||Daryl Eicher (Oracle)||OIC|
|Creating net new apps on top of Netsuite with OIC Visual Builder||Niall Commisky (Oracle)||VBCS + OIC||NetSuite|
|Monitoring API – Getting Activity Stream data||Niall Commisky (Oracle)||OIC|
|Triggering an OIC integration via OCI Events – the Notifications Service Approach||Stan Tanev (Red Thunder Blog)||OIC||OCI|
|The 5 Pillars of Intelligent Invoice Processing||Daryl Eicher (Oracle)||OIC/Arcivate||RPA|
|B2B – EDI Translation support||Niall Commisky (Oracle)||OIC||EDI|
|B2B Document Management||Niall Commisky (Oracle)||OIC||EDI|
|Process large file (above 10MB) in Oracle Integration Cloud Service (OIC)||Harshit Yadav (K21 Academy)||OIC|
|SOAP Vs REST APIs In Oracle Integration Cloud (OIC)||Harshit Yadav (K21 Academy)||OIC|
A couple of days ago the updates for OIC included a new feature B2B (April 2020 new). Specifically, support for EDI X12. Whilst this doesn’t mean SOA Suite B2B is redundant yet (as that still offers a broad range of other complex exchange protocols HL7, EDIFACT, SAP iDoc – complete list here). I wouldn’t be surprised if Oracle considers leaving behind support for one or two of the more complex file formats such as EDIEL. But with X12 cracked, I wouldn’t be surprised to see EDIFACT follow soon.
SOA CS future?
So where does the leave SOA CS given one of the differentiators to OIC was the existence of the B2B and MFT elements? OIC has not yet fully displaced SOA and SOA CS, there are use cases that OIC can not yet fully address. For example in the MFT space OIC has caps on filesize (whilst MFT does not). MFT also supports Applicability Statement (AS) standards (IETF specification for AS2). Unlike some of the payload formats, particularly the metadata-driven ones we may see fall away more quickly, the AS standards provide the means for communications to be responded with a ‘Message Disposition Notification‘ (MDN) which means the receiver will tell the sender the receiver has safely and fully received the communicated payload – non-repudiation. We have seen banks and other data-sensitive organizations continue to use such standards (after all you want your employer saying they told their bank to pay your salary, and the bank say, nope not got anything or transfers between the bank and the tax man).
How quickly these gaps will be addressed in OIC is not clear, or whether these cases will be addressed, or whether SOA will continue to answer these edge cases until superseding standards and techniques make them redundant.
The bottom line is there are too many customers with legacy estates on-prem for SOA CS to be retired any time soon. However, I would not be surprised if SOA follows the route of ODI when it comes to Oracle Cloud. Oracle has developed ODI on Oracle Cloud Marketplace, which provides an on-prem style deployment configured (and presumably tuned) to run on Oracle Cloud as an IaaS Virtual Machine. This potentially simplifies the BYOL license model leaving the customer responsible for a level of patch maintenance (be that take a new ODI Marketplace instance spin it up and apply the configuration, then drop the old one, or run the traditional patch processes).
We will see SOA continue to be patched and maintained for a long time to come. But I wouldn’t surprised if Oracle makes it more and more attractive for SOA customers to use OIC – possibly combining OIC and their SOA Suite instances with a view that when customers need to update migrations, they consider the port.
Whilst this may sound like Oracle are potentially leaving customers without the infamous paddle. However, our experience in the partner space is that Oracle seeks to enable them and recognize that most partners are very capable. Not to mention, when the heat is on, partners with middleware Aces can usually find their way through the Oracle organization to get what is needed.
I think we’ll continue to see a number of Oracle’s specialist partners file the gap with tooling adapted from on-premise solutions. It is these partners that also have the wealth of expertise on knowing to get the most out of SOA Suite and keep it secure.
So OIC will continue to absorb capabilities that had separated it from SOA suite cementing it as the mainstream offering. But the old warhorse will be around for a long time (remember many older companies still use Cobol successfully) yet. To use a car analogy, those sticking with their trusty vintage Mark 1 Golf that has done 500,000 miles will have to stop looking to the manufacture for service and parts and enlist the support of a passionate specialist.
To be clear, this is only our opinion, and not informed or confirmed by Oracle.
This month’s new articles about Oracle Integration Cloud …
The catalogue of articles we’ve been maintaining here has become substantial and a bit unwieldy to maintain (and we think to use). So we’re going see how periodic posts for the latest resources works. We’ve added a new post category to the blog called CollectedArticles, which will make it easy to filter out all but these posts.
We’ll continue to include the references to who the post was from, and the aspect of OIC that is relevant.
As we haven’t updated the resources for a while, this is going to be a bit larger than normal.
|Article / Link||Author||Subject Matter||Connecting|
|SOA Suite 18.104.22.168 / OIC interoperability||Nial Commisky (Oracle Prod. Mgmt)||Adaptors||SOA Suite|
|OIC NetSuite Adaptor||Nial Commisky (Oracle Prod. Mgmt)||Adaptors||Net Suite|
|New Connector for Box||Nial Commisky (Oracle Prod. Mgmt)||Adaptors||Box|
|Object Storage with Oracle Integration Cloud||Red Thunder||Adaptors|
|Using Visual Builder for Process Task Forms||Nial Commisky (Oracle Prod. Mgmt)||VBCS / PCS|
|OIC Feature Flags||Nial Commisky (Oracle Prod. Mgmt)||Core|
|CPQ Integration (Part 1, Part 2)||Nial Commisky (Oracle Prod. Mgmt)||Adaptors||Oracle CPQ|
|Fusion ERP Batch Imports with OIC||Nial Commisky (Oracle Prod. Mgmt)||Adaptors||ERP|
|Why and How to Integrate Oracle Policy Automation with Oracle Integration||Cristian Silipigni (Oracle Solution Engineer)||Adaptor||Oracle Policy Automation|
|Testing REST trigger-based Integrations in OIC Console||Sumit Tomar (Oracle Snr Technical Staff)||Adaptors|
|Encrypt/Decrypt capabilities in Stage Files||Bipin Kumar (Oracle Tech Lead)||Adaptors|
|Integration Patterns – Publish/Subscribe (Part 1, Part 2)||Daniel Martins Teixeira (Oracle Tech Solution Engineer)||Core|
|Using the next generation Activity Stream||Mamta Sangwan (Oracle Snr Tech Staff)||Core|
|Send Notification with attachment||Ankur Jain (Oracle Ace Associate)||Adaptor|
|Editable Table in VBCS||Ankur Jain (Oracle Ace Associate)||VBCS|
|Oracle ATP Adaptor||Ankur Jain (Oracle Ace Associate)||Adaptor||Autonomous Transaction Processing|
|Defining and using constants||Jans Kettenis||Core|
|Auto-Mapping Elements in the Data Mapper||Jans Kettenis||Core|
|Progressive Web App UI Experience||Harish Vinayachandran (Oracle)||Core|
|ICS – XSLT parameters that are not found but are being used ???||Marcel van de Glind||Core|
|How Much Oracle Integration Cloud Do I Need?||Rubicon Red||Core|
With the recent announcement of working with Automation Anywhere (press release here) adding to the partnership already in place with UiPath, Oracle’s approach to Robotic Process Automation (RPA) is differing to other players such as SAP and Pega Systems for example who have acquired vendors.
It is an interesting question as to whether partnering is the right solution given that RPA vendors can and do challenge the need for an integration platform. After all with the exception of IoT most solutions have an some form of UI or API the robot can connect to. This assertion whilst isn’t wrong it fundamentally overlooks the ability to push transaction volumes through, UIs are vulnerable to change, the ability to apply very robust security. But when discussing integration needs with business rather than technology leaders such factors can be so easily overlooked.
Whilst acquisition is a possibility, unless Oracle acquires one of the big three (Automation Anywhere, UiPath, Blue Prism) they are likely to end up with a less established and/or less feature rich offering, that could very easily be perceived as an expensive OIC adaptor. Where as by having now partnered with two of the three major players, it is easier to sell the story that the technologies can be complimentary.
So how do they compliment rather than compete? The traditional buyer of OIC is an IT team either corporate or departmental. Such teams are often constantly being pushed for new Integrations to and often the most problematic of these are the smaller demands for proof of concepts etc that drive innovation forward, or enables the next new business opportunity or short lived integration need. By introducing support for RPA means several possibilities …
- Reverse the sales story, where an RPA sale has displaced traditional PaaS but the scale up has become too costly then the pitch can be it’s easy to make smooth transition to a PaaS solution by using the adaptor to streamline the use of RPA where it is needed,
- Using RPA against services the have changing and regularly enhancement are likely to suffer from the need to continually maintain the RPA scripts. If this happens a lot then the RPA model will feel very brittle. Whilst this is a plus from an iPaaS perspective, we don’t want the fact that perhaps central IT have suggested RPA as an interim solution and therefore end up being to blame for the effort involved in maintaining brittle scripts,
- RPA can be used by less technical users to effectively develop and prove business needs and thinking before an often over stretched IT team get involved – use RPA fed with appropriately sourced data via Integrations to help determine/prove business idea, before making the larger investment in a scalable robust solution,
- Integrations can be exposed and extended using RPA for tactical short term fixes, if the pilot proves value, and the next step is scale up – then replace RPA with OIC.
The last of these possibilities is very interesting as we’re moving towards what could be described as the citizen adaptor (in the same sense of having citizen developers).
Central IT teams embracing the idea citizen developers and integrators means rather than what is sometimes referred to as Shadow IT being that only a shadow with no visibility of what is happening. By embracing the idea, we create the opportunity to:
- Influence/set the parameters for the tools being used – increasing the chance of ensuring efficiencies in investment (and/or license compliance),
- See if common solutions or problems are occurring across the organization therefore focus efforts of building strategic solutions that deliver the biggest return on investment,
- Potentially leverage efforts from shadow IT teams for the benefit of the wider organisation,
- Most importantly opportunity to monitor what is happening to ensure legal and contractual compliance is assured e.g. if corporate policy prevents the use of cloud storage services from being used to hold certain types of data – it will be easy to see what Integrations exist with such services, and then review the data involved.
In this light working with, rather than trying to compete against the market leading RPA vendors has the distinct potential to present OIC as a strategic enabler.