CloudAnnotation

  The article gives the sample scripts with the use of Oracle Fusion Cloud REST APIs in Groovy. it includes all the crud operations and some advanced methods to access the REST APIs. Register REST API in Webservices under the application composer tool. Refer below article to register the REST API. Always prefer not to use the web services, instead consider using Groovy functions for CRUD operations as a web service call is more expensive than a Groovy call in terms of performance. Test the web service thoroughly in POSTMAN/any other client with samples and then use it in Groovy. Use try-catch when calling REST calls to handle errors. GET Operation: Simple GET Call 1:  To get or Read a specific record use the below code. we don't need to pass content type etc. URL to Register in Webservices: https://abcd-dev1.fa.ap2.oraclecloud.com:443/crmRestApi/resources/latest/opportunities/##OptyNumber## def OptyNumber = OptyNumber def x = adf.webServices.GET_Opportunity.GET(OptyNumber)...

  The article gives the sample scripts with the use of Oracle Fusion Cloud REST APIs in Groovy. it includes all the crud operations and some advanced methods to access the REST APIs. Sometimes only groovy can't be used to fulfill the requirement. we might need web services to connect the two systems or the same system in groovy. Oracle Fusion Cloud will allow web service usage in groovy after registering in the application composer with host details and the path. this article will explain the optimum way of using web services in oracle fusion cloud groovy. Benefits: 1) Use a single web service for multiple objects if it is a similar endpoint structure. 2) Minimum No of  Webservice registrations in application composer. UseCases: 1) Use a single web service for creating lead/opportunity/account/contact/custom objects. 2) Use a single web service to update any entity child object in the oracle fusion cloud. Important Notes: a) The host can't dynamic in the oracle fusion cloud. i...

  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) (...