Step-by-step guide discovering how to provision and build a business processwith OCI Process Automation
OCI Process Automation (shortly OPA) is an OCI PaaS Oracle Managed cloud service which helps customers to build their business processes based on Structured or Unstructured models. This is the best solution to easily manage business processes granting to business users to build their own implementations without coding but just using a web browser and drag&drop capabilities… what we usually call a “no code” environment
The article has the goal to explain how, step by step, we can quickly test the features included in OPA… starting from my experience with the tool.
Just to simplify the explanation, I will describe a “happy path” process … in my example building one business process which usually is quite loved by everyone…. mainly when talking about the Vacation Request Approvals 🙂
I have been recently engaged in one assignment where I was expected to make connectivity with NetSuite to create Customer inside NetSuite. However, condition was to connect NetSuite using “Token based Authentication” only. That was Customer’s key requirement to establish secure connectivity to NetSuite.
Token based authentication needs many input parameters such as WSLD URL, Consumer Key, Consumer Secret, Token, Token Secret and Account ID.
I had to spent bit of time to work-out how to get all above parameters values and in this blog I just want to share that learning.
There is already NetSuite Connector Documentation available which describe the instructions about Token Based Authentication. This blog is just expanding that document with some additional info and screenshots.
Everyone is aware of the continuous integration and continuous development relevance which is nowadays the mantra of DevOps practices.
Oracle Integration is obviously part of the end2end lifecycle development being involved for connecting legacy applications usually deployed on-premise and SaaS applications often provided by Oracle Cloud or hosted on other Cloud providers.
It doesn’t matter where the applications are, where the integration is; the continuous delivery of new integration processes and versions need to be included in a smart and automated tool able to reduce the gap between the different developer teams.
Developers, who have the ownership to build new services and IT Operators, who have the task of deploying new code versions to the different environments, need to converge on one single tool to simplify complex procedures that can be simply considered as two sides of the same coin.
The common need is to keep all environments aligned with the latest implementations, possibly having everything monitored and tracked to grant audit activities in terms of compliance; this is a must when the project is starting to become critical and relevant at the enterprise level.
Oracle Integration (OIC), as you know, includes Visual Builder Cloud Service which allows open-source standards-based integration to develop, collaborate on, and deploy applications within Oracle Cloud.
Just for this, it’s easy to use Visual Builder Studio, the built-in tool, that allows developers to manage the software life cycle automating the development.
Oracle VB Studio natively supports Oracle Integration artifacts, so we can leverage this one to easily promote our integration flows from an environment to another one moving for example our integration projects from development to test environment once you we completed the new implementation and of course ready to test it.
That’s the right path to be used for promoting projects from Test to Production or from Production to a DR environment, this one probably running on a different OCI Region.
Working with the current implementation you can:
Export integration flows
Import integration flows
Delete integration flows
As shown below in the picture, the options we have working with Oracle Visual Builder Studio and OIC
Herewith an example of pipeline that you can easily configure to automate the Export / Import procedure and defining in cascade all steps (“jobs”) to define the required actions, of course this one below just for demo purposes. This procedure will be later explained step-by-step just in case you want to reproduce this one for your own purposes
In order to export our assets from the development environment, for example, it’s enough to configure our source and target environments about the OIC instances
How to configure our OIC environments?
This is a straightforward operation working with VB Studio, as shown below:
We can create all connections we need to configure properly the tool
Once we have configured our instances, we need to build our “pipeline” so to automate the procedure when needed
Each pipeline can include all “jobs” we need (in the previous screenshot we have used two different jobs “select your OIC project” and “import OIC project”) so to build the right chain among the different available “jobs”
To create a job, select the Build link from the left panel of the Visual Builder studio and then we can create a new job
Each job has some options and parameters to be configured as below the screenshot shows:
Select the “Parameters” tab to configure the string parameter:
The “Default Value” is the value of the integration flow version on our OIC instance to be selected and moved to the new instance. Of course, this value can be changed when we run the build so to properly set the right integration flow version
Now it’s time to select the “Steps” tab to identify the OIC instance from where we want to export our integration flow
If needed, we can also include the asserter recording just flagging the box. In this case we are moving (exporting / importing) the integration flow named “ECHO” and working with its *.iar file once we have exported this one.
Now you can click the “After Build” tab to configure it as below described. The *.iar extension is the default extension of the integration flow when you decide to download it.
Click save and that’s all. Our first job is properly configured now.
To proceed we are now ready to configure the second job (“import OIC project”).
In this case, the first step to be accomplished is the configuration of the “Before Build” tab as below shown and adding a “Copy Artifacts” option
And now, as we did with the first job, we can properly configure the OIC instance target, in our sample, but in this case for the import action.
We can also check the box about the “activate integration” option so that our integration flow will be imported and started just to have this one ready to be invoked by applications
Also, in this case, we can now save our configuration.
Once these operations have been completed, we are ready to test our pipeline selecting the start button on the right side of the web page and below shown
If the execution of our “build” is properly configured, we can see the “green flag” of our jobs once we run it
Furthermore, we can drill down the execution to look at the log information just in case something wrong having also the chance to download the file including the log for further analysis or if we need to share this one with other people or applications.
From the Visual Builder Studio “Home page” we can also get information about statistics and previous executions so to track the activities managed on the different resources we have
This is for sure the best way to properly manage our environments and the best approach to have under control the lifecycle of our projects and their deployment.
For further information, look at the really interesting content already published here:
Integration platforms are often required to handle confidential information such as personal details, payment information or other data protected by compliance and regulatory standards such as HIPAA, GDPR, PII and PCI.
Various methods exist to protect data from unauthorized access while data is in transit and at rest. These approaches typically encrypt the entire payload. As a complementary approach Field Level Encryption has an important role to play by ensuring that only appropriately configured clients can read sensitive data fields. This approach also allows clients without the encryption keys to work with the non-sensitive data which would be impossible to do with a fully encrypted payload.
Although Field Level Encryption (FLE) is not natively supported in Oracle Integration (OIC) today, this blog will explore several options that will allow you to implement FLE with OIC. In this blog, I will present these options, discuss some guiding principles and showcase some sample implementations.
In this blog post I will explore how we can extend the native capabilities of Oracle Integration (OIC) with Oracle Functions to process Excel files.
Although OIC can handle a number of file formats natively, .xlsx or .xls files need a bit of extra love.
The inspiration for this blog comes of the back of several customer enquiries into this subject.
The simple solution for most customers is to convert the Excel file formats to CSV and subsequently process them with OIC. I will use this approach here too but with a little bit of help from other OCI services such as Oracle Functions, an API Gateway and Object Storage.
In a two-part blog series I am exploring the available options in triggering an Oracle Integration Cloud (OIC) integration whenever a resource state change occurs within Oracle Cloud Infrastructure (OCI). One example of this event based pattern is the ability to trigger an OIC integration as soon as a file is uploaded to OCI Object Storage, thereby removing the need for any scheduled based integrations that rely on file polling.
In my previous blog, I provided some context and background on the OCI Event service and the available options that we have in triggering an OIC integration. Namely these are the OCI Notifications, Functions, and Streaming services. My previous blog also explored the first of these patterns, and detailed how this event based pattern can be achieved using the OCI Notification Service. In this follow up article I will cover how we can use Oracle Functions to achieve the same outcome.
Oracle Integration Cloud (OIC) is Oracle’s next generation modern Integration solution Platform as a Service (PaaS) offering. The core purpose of this product to integrate various SaaS and On-prem systems real time. In addition to Integration capability, it also provides Process Automation and Visual Builder Capability. Details docs are available here.
OIC has concept of Adapters. There are huge range of adapters available and documented here.
One of the Adapter REST Adapter been used to expose an Integration to outside world for consumption. In order word, it’s an entry point for most of Integrations what we developed using OIC. It also gets used to invoke any external REST based endpoint.
REST Adapter support Basic Auth and various flavour of OAuth as security mechanism to protect the Integration access.
However, not all OAuth flavour supported for Trigger Role (Used as Entry point of Integration) vs Invoke Role (Used for invoking third party REST endpoint).
REST APIs exposed using the REST Adapter (Trigger Role) are protected using Basic Authentication and OAuth token-based authentication.
REST API consumed using the REST Adapter (Invoke Role) Support HTTP Basic Authentication, OAuth Client Credentials (two-legged flow), OAuth Resource Owner Password Credentials (two-legged flow), OAuth Authorization Code Credentials (three-legged flow), OAuth Custom Three Legged Flow, OAuth Custom Two Legged Flow, OAuth 1.0a One Legged Authentication, Amazon Web Services (AWS) Signature Version 4, and Oracle Cloud Infrastructure (OCI) Signature Version 1. There is also support for consuming APIs that are unprotected.
Now, majority of Customers chose Basic AUTH while publishing an Integration because it’s very simply to implement but has limitation because the user password gets expired in every 3 month which result changing all Integrations configuration again in 3 month of time. We can very well avoid this problem by Implementing OAuth token which never gets expired.
Oracle has official document for setting up Service Account without expiry but it’s quite difficult to follow instructions from that document. Hence, I thought to publish more user friendly instructions to achieve the same outcome.
In this blog, I will be covering how we can invoke an Integration exposed using REST Adapter (Trigger role) using OAuth token which doesn’t get expired.
Customisation is essential part of any SaaS implementation to capture unique business needs. In Salesforce SaaS application also, there could be several use-cases where user might need to create a new Custom Object or add custom fields into existing Standard Object such as Contact, Account and Organisation etc. In this blog I will be showing how can we add Custom Object e.g. CochOrder which can have multiple Custom Fields e.g. Order Number, Shipping Cost, Source Region, Target Region and Total Amount etc. and can update that Custom Object fields using Oracle Integration Cloud (OIC) Salesforce adapter. I must recommend you to read my other blog which I have wrote to cover adding Custom Fields to existing Standard Object such as Contact, Account and Organisation etc. Most of the steps is going to same as previous blogs, so I am not going to repeat them here, instead will be only focusing only new changes related to Custom Objects.
Before, I go into deep drive, just want to highlight the core objective of this blog to show Salesforce configuration and OIC Salesforce adapter configuration, I am assuming reader has already basis understanding of OIC product features such as Connection, Integration, mapping and deployment.
My colleague had already covered Salesforce Inbound and Outbound integration using Oracle Integration Cloud Salesforce Adapter. So, I might not be repeating few steps which already been covered in this blog as well. if you doing Salesforce Integration first time, then its recommended to review these blogs before you proceed to read this blog.
So let’s do deep dive now. Below are the high levels flow and steps which needs to be performed to achieve desired result.
Oracle’s two major ground breaking innovation last year were Autonomous Data warehouse (ADW) and Autonomous Database Transaction processing (ATP) both are database offering suitable for different workload and are self-driving, self-securing, and self-repairing in nature. If you want to read more about these services then please go through above links.
ADW/ATP both can be quickly provisioned on Oracle Cloud Infrastructure, it’s take less than 5 minute to spin ADW/ATP instance and database is ready to connect.
User can use Oracle SQL Developer to connect to ADW/ATP database as long as they are supported version. These DBaaS services also offers out-of-box browser based SQL Developer tool which can be used to run any kind of SQL statements.
Here is sample snap of browser based SQL Developer capabilities –
Once user has Database ready, obviously there could be requirement to access data residing inside ADW/ATP instances.
Fortunately, Oracle Integration Cloud provide Adapter for connecting ADW/ATP instance, click here to know more about ATP Adapter capabilities –
In this blog I will be covering simple steps how you can connect to ADW/ATP instances using OIC Autonomous Transaction Processing Adapter (ATP) Adapter.
I made assumption that ADW/ATP instance already exists. if you not sure how to create ADW/ATP instance then refer this blog which was written by my colleague who already explained how to create ADW/ATP database instance and connect from SQL developer.
So, let move forward. Login to your Oracle Integration Cloud (OIC) home page >> Integration >> Connection >> Create >> search for “Oracle ATP” >> select the same