Before we dig into the logs, the following is a brief list of things you might consider checking if integration(s) stop working:

As we have seen, it is possible to lock at the error information for a specific integration instance. This information is normally a brief extract from the logging information. The alternative approach to this is to retrieve the log files from the underlying server(s); an approach that requires a great deal more effort.

When errors are not obvious, such as connection losses or subtle errors in your service, it will be necessary to examine the log files. The log files, as you will have seen, can be accessed from several locations. When retrieved, you will have a ZIP file downloaded that contains all of the log files from the servers that are running the ICS service. This will typically be two servers and an admin server. The admin server runs the UI for ICS, so any errors resulting from creating and editing integrations will appear here. Errors that could occur during the running of an integration could show up in any of the server logs. If you connect multiple ICS integrations together, as you do in a publish and subscribe, there is no guarantee that all the related integrations will appear in one log file.

This is presently a challenge, if you want to see what happened in what order when examining complex cases, but there are tools that can merge log files easily, for example LogDistiller (https://sourceforge.net/projects/logdistiller/).

Having located the error, the next step is to locate the initial error for our integration. It is a common mistake to look at the last error, as it will be the closest to the end of the log - but often this is a reflection of a subsequent error, rather than the initial problem that will have caused subsequent problems.

There is always the possibility with any sophisticated software that something will not behave as expected or a problem will occur. While we hope that this will not happen, it is better to be prepared and to make it easier for the Oracle support team to investigate. To this end, ICS has a mechanism to raise an incident within the user's drop down menu, as you can see in the next diagram. This option will create a popup where you can capture information about the incident to advise Oracle what the problem is. When the incident process is started behind the scenes, a range of valuable pieces of information are captured.

When the incident details are completed and you click the Create button, the incident is given a number and it is reported to you on the main screen, as you can see in the following diagram:

It is then possible to download all the details by clicking on the Monitoring dashboard's Download Incident, which will present a popup dialog to identify the incident number. Once the number is provided and Download button is clicked, then a ZIP file with all the relevant captured information is provided. This information can then be passed back via Oracle's support portal as shown in the following diagram:

As with newer products, information on how to troubleshoot errors, and building into the software actions to try prevent users making mistakes, tends to lag a bit behind the features being offered (which is understandable, would you rather have lots of connectors that can cover 90% of use cases or a couple of connectors that help you though those esoteric 10% of situations?).

All of this means we do need to source information to help address those more troublesome cases. The following table describes the different places that can be used to help. It is worth remembering that ICS has been built on top of some core Oracle technologies, so some of the resources will relate back to the underlying areas. As previously mentioned, the most significant contributing technology to ICS is Oracle Service Bus.