This blog is the third in the FlexDeploy Loves OIC blog series, stay tuned for subsequent entries in the series.

Oracle Integration Cloud (OIC) provides the ability to develop an integration in the cloud.  The integration can connect cloud and/or on-premise applications; however, these integrations are maintained directly in the cloud and not in any Source Code Management (SCM) system.  Applying the DevOps principle of Continuous Integration with OIC isn’t as straight forward as it is with a SCM system to watch for changes.

I will walk you through the support that FlexDeploy provides for change detection for an OIC integration.  We will cover how the change detection is accomplished, saving the changes to a SCM system and then utilizing the SCM system to initiate a build of the integration along with creating an artifact.

FlexDeploy Configuration

To assist in utilizing Continuous Integration, we will create a utility workflow and utility project that will be used to check for changes in the OIC instance.  The workflow will use the exportUpdatedIntegrations operation to determine when changes occur and will also save any changed integrations to a GIT repository.  Let’s start with the utility workflow by clicking on the Workflows page, click on the plus sign and configure as follows:

 

Once saved, click on the definition tab and we can start adding the operations that we need.  We will save any changed integrations to a GIT repository and will start with a clone of the GIT repository into the plugin temp location.

  1. Instance Code – this is the code value of the GIT instance created for the repository
  2. Sparse Checkout Folder – this provides a limited view into the repository
  3. OK

Now that we have the current integrations cloned locally, we can add exportChangedIntegrations operation (OIC plugin) that will retrieve all integrations to get current update date time values.  These values will be compared against a copy of the previous retrieval to determine if a change was made.  If a change is detected, the changed integration will be exported into the plugin temp directory and directly overlayed into the cloned integrations.  This will allow the files to be easily added to the Git repository.  The most recent integration retrieval is then saved to the local copy, ready for the next detection run.

To configure the step:

  1. Integration Exclude List – csv list of integrations to exclude from the change detection, blank is none
  2. Integration Include List – csv list of integrations to include for the change detection, blank is all
  3. Export Subfolder – directory where changed integration will be placed under the temp directory, this should match your Sparse Checkout Folder, so the changed code is added directly to the cloned repository
  4. Expand Integrations – determines if the iar file should be expanded so we have each file. Default is the iar file only.
  5. OK

We have any changed integrations exported to the temp/subfolder directory.  We need to add any files to the local repository so we will use the add operation (GIT plugin).

  1. Instance Code – this is the code value of the GIT instance created for the repository
  2. Local Repository Path – defaults to the temp directory, only change if repository is somewhere else
  3. File List – what files to you want to add, * means all files
  4. OK

Once the files are added, we need to commit the changes to the local GIT repository.

  1. Instance Code – this is the code value of the GIT instance created for the repository
  2. Revision Message – provide a message about the change, this can be a groovy script to allow more flexibility
  3. OK

Now we just need to push any commits to the remote GIT repository.

  1. Instance Code – this is the code value of the GIT instance created for the repository.
  2. Branch – need to indicate the branch to push the changes to
  3. OK

All operations have been added and the workflow should look like the following.  Make sure that you activate the workflow so that it can be utilized in the utility project that we will build next.

Now we have the new utility workflow, let’s create the utility project that will be executed on a schedule to check the OIC instance for any changes to any of the integrations.  Click on the projects page and create a new utility project.

Configure the project with the utility workflow that was just created and the instance of the OIC server.

One last configuration; switch to the Continuous Integration tab and setup a scheduled execution of every ten minutes.  Make sure to save the project.

The utility project/utility workflow will update the changes to this integration into a GIT repository.  This project can be utilized for multiple integrations.  We now want to re-configure the FlexDeploy project that was created in the first blog and have the project perform a continuous build whenever changes are detected.  Open the Project page and double click on the PROCESS_HR_REQUEST project under the HR_OIC application.  Select the Configuration tab (blue) and configure as follows:

  1. SCM Type – Select Git from the drop down.
  2. Git Instance – Select the Git Instance that contains the integration code.   We saved our integration changes to a GIT repo, this must be the same one.
  3. Branch Name Script – Set to StreamName, this is a variable that will be replaced by the value in Stream Name (master)
  4. Sparse Checkout Folders Script – Set to the folder where the given integration is located in Git
  5. Stream Name – Set the appropriate Git stream
  6. Save the project

 

We can now add continuous integration to the project by selecting the Continuous Integration tab (yellow) and we will configure as follows:

  1. CI Type – select Poll SCM Trigger, this will continuously poll the project in the repository
  2. Environment – select the environment to build the project
  3. Stream Name – select the stream from the project to poll
  4. Interval Minutes – how often to check the project in Git
  5. Save the project

One more modification is required.  We created the exportIntegration workflow with an exportIntegration operation that would communicate directly with OIC.  With the continuous integration we have configured, we need to adjust the workflow to export the changes from Git and then build the integration for deployment.  We will perform the following changes to the exportIntegration workflow (a new workflow could also be created and connected to the project):

  1. Open up the exportIntegration workflow and click on Definition tab
  2. Make a copy of the workflow
  3. Delete the exportIntegration operation
  4. Drag the cloneProjectSources operation from Git plugin to the workflow palette (no additional configuration required)
  5. Drag the buildIntegration operation from OIC plugin to the workflow palette (no additional configuration required)
  6. Make the workflow active.

The final workflow will look like:

Execution

Now that we have added the new project and made the appropriate changes to the existing components, we can make a change in OIC for the integration and watch the entire process execute.  At the end, we will have an integration artifact that can be deployed to any OIC instance without any human touch.

A change was made at 9:00pm in OIC and the CheckForOICChanges project (utility) detected the change at 9:02pm.

Now that the project detected and saved the changes to the Git repository, the PROCESS_HR_REQUEST project (standard) will detect the addition of new files in the Git repository and execute the build within the 5 minute interval.

Click on the execution id link.  Click on the artifacts tab and see that the following artifacts were created:

  • Connections (.json)
  • Integration file (.iar)
  • connectionPlan (.properties)

Conclusion

This was the third blog for the FlexDeploy Loves OIC series and covered how to configure FlexDeploy to achieve Continuous Integration with OIC, which is a cloud application that doesn’t save code in a standard SCM.  In the next blog, we will build on the work that we have completed and add automated testing of the integration through the built-in testing framework within FlexDeploy.

Previous Post: FlexDeploy Loves OIC: Manage connection property replacement

Next Post: FlexDeploy Loves OIC: Automated Testing

Dan Reynebeau

I have been working with Oracle and IBM integration technologies, along with custom development, for over 20 years providing solutions to the customer. While working with the different platforms, I have developed deployment scripts along with utilizing 3rd party deployment products to automate the deployment process. As a Principal architect at Flexagon I work with customers to enable DevOps/CI solutions using FlexDeploy, as well as primary development of FlexDeploy.

More posts by Dan Reynebeau

Leave a Reply

Your email address will not be published. Required fields are marked *