Once you have developed your ICS services and they are running as desired, you are going to quickly reach a point where you will want to separate development and testing from your running integrations, so that any additions or changes do not disrupt or create inconsistencies in the target systems you have integrated. The worst thing would be to need to resolve data consistency and integrity issues in your target solutions, as lots of small changes will mean a lot of inconsistency in a live environment. So, separating your test and development from a live setup means no consistency issues, but raises the question of how we move our integrations from development to production? This is where import and export comes into play.

This scenario leads neatly onto the consideration of using a configuration management repository. As you develop the service configuration, you may wish to create milestone copies of the service implementation. So, if as you make further changes and you decide things are not satisfactory, you can always retrieve the milestone from the repository and deploy it back into ICS.

It is possible that you want to run the same integrations for different instances of the same systems in another part of the world; these instances may then cooperate. This approach of clouds working together can be described as a federated deployment model. Rather than those systems sending data across the world to be manipulated and inserted into a system that may also be in another part of the world, you may choose to deploy the integration logic to the different data centers Oracle offers. As a result, the data does not take so long to reach the integration or destination and reduces the risk of having problems such as data residency (also known as data sovereignty).

The additional benefit of duplicating the integrations to different data centers is that, if you have external routing, in the unlikely event of a whole data center failure, it is possible to continue processing. This is not to say that we expect Oracle data centers to fail, but it does happen, and when it does often with dire consequences, Even the most experienced providers, such as Amazon AWS, have been caught out.

Oracle is actively encouraging the user community, as well as third party software vendors, to offer pre-built integrations for ICS through their marketplace (https://cloud.oracle.com/marketplace/), where you can buy, and in some cases get for free, additional features that you can run in Oracle's cloud. In this situation, you will be given a package of integrations that you will then want to load into your environment.

Within integration flows, it is possible to have lookup values that can be used to swap the presentation of information from one format to another. In an organization with good data governance, it is possible that these lookup values will be mastered somewhere outside ICS. This might be with Oracle SOA Suite and the Domain Value Mappings (DVMs), or even a completely different third-party tool. In these situations, to keep the mappings up-to-date, or at least synchronized between different tools, you need the ability to export and import these values so different solutions operate with consistent lookup values.

In some circumstances, it can be more practical to work through a tool that can edit XML directly, particularly when need to edit complex expressions. This kind of scenario was briefly illustrated in Chapter 5,Going Social with Twitter and Google. Ultimately, many editors will make life easier for you in most cases, but occasionally it does become quicker, although more error prone, to avoid the helping hand, or to use a more powerful tool such as JDeveloper or XML Spy. Even today, there are times when dropping into raw HTML or XML views to make a minor change can be easier.