|Article / Link||Author||Subject Matter||Connecting|
|OIC & OAuth 2.0 (Part 1, Part 2, Part3)||Niall Commiskey||OIC|
|OIC Responsys Adapter||Niall Commiskey||OIC||Responsys|
|OIC On OCI Status Page||Elizabeth Earle||OIC|
|Create Schedule Service SOAP Connection||Kabir Yadav||OIC|
|Schedule BI Publisher Report through OIC||Kabir Yadav||OIC||BI Publisher|
|Subscribe to HCM Updates ( via ATOM Feed )||Kabir Yadav||OIC||HCM|
|Configure Oracle HCM Cloud Adapter Connection||Kabir Yadav||OIC||HCM|
|Subscribing to Business Events in OIC||Yan Scorrer||OIC|
|Split a CSV file into multiple based on a column in OIC||Ankur Jain||OIC|
|How to create and test custom ESS job in Oracle SaaS||Ankur Jain||OIC|
|Reading the latest file from SFTP in OIC||Ankur Jain||OIC|
Another month passed already, so here are Feb’s posts.
It appears to have been an unusually quiet month, but that could be a reflection of the OIC release cycle as we’ll probably hear about the next feature set updates late in July.
Blink and it’s another month gone. But Oracle has been very very busy as we come around for the latest quarterly updates and the details published. Plus a lot about Oracle Hospitality Integration Hub (OHIP) which builds upon OIC.
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 …