I experimented with ICS on two use-cases. I wanted to proxy SOAP and REST requests. For the SOAP request I used a SOA-CS Helloworld web-service and for the REST request I used an Apiary mockservice. I will not go into basics too much such as creating a new Connection and using the Connection in an Integration since you can easily learn about those in other places.
ICS: Calling a SOAP service on SOA-CS
When you want to call a SOAP service which you have exposed on ICS, you require two sets of headers. The WS-Timestamp headers and the WSS-UserName token headers (with the password in plain text).
This is required even when you have not specified a security policy (currently username/password token and basic authentication are supported). When you don't provide them, you get Service Bus errors (as shown in the screenshot below) which indicates ICS is running on the Service Bus (in case you didn't know this yet, it is no secret). This was not required when directly calling the SOA-CS service.
The ICS console also showed me something had gone wrong
However I could not get more details from ICS on the error. SOAP-UI indicated the error was in the response pipeline. SOA-CS did not show any instances or any indication in the log files that the service had been called. Eventually it appeared (trial and error) I was sending basic authentication headers along with the message. I removed them and the request/response worked.
I did find out though that logging can only be done on so-called leaf nodes. I have not seen a way to log the entire message.
ICS: Calling a REST service on an Apiary Mock
I used Apiary to create a mock REST service which was quite easy.
Apiary allows easy creation and syntax checking of API blueprint and Swagger API descriptions. From these descriptions it creates mocks and generates simple client software in different languages. The mock server logs the request header and response header and body.
Apiary can do much more such as generating tests for your API based on the blueprint. Watch a short movie about it here. Apiary was a good fit to do some testing on ICS and the ICS REST Adapter.
You should mind that the base URL needs to be specified in your Connection and the path of the URL needs to be specified in your Integration.
You can obtain information about your exposed API from the information link next to the Integration.
The provided metadata gives you information on how you can call your API.
If you've done it the right way, you should get a response.
If not, you might get something like:
In the second example I did not send a payload with the request. You will not get a clear message about this.
XPath in ICS
You can use several XPath expressions in ICS to do mappings. In order to access this functionality, you can do the following. First deactivate an Integration so you can edit it. Open the integration and edit your mapping.
Next click the target field in the Mapping column to the right and the following screen will pop up;
Here you have a GUI to allow you to graphically use XPath functions such as translate and concat. You can even do things like for-each and if statements. You can however not look at the generated XSLT or edit it directly. In order to do that you can however export an Integration, extract it with your favorite archiving tool and look at/edit the generated code. XSLTs are under processors, resourcegroup.
This gives you an XSLT like for example:
When you modify this, re-ZIP it and import it:
You can get the following error if the ZIP structure is not correct:
And the following error if an Integration with the same name is still active:
And the following messages if both above requirements are satisfied:
Thus you can edit your transformations outside the ICS web-interface. The process to get the transformation back in though requires some steps, which might not make this process suitable for quick iterative development.
Editing Connections and Integrations
As a developer I'm used to working quickly in an IDE and have access to everything. ICS feels limiting to me and difficult to debug. For getting the SOAP and REST integrations to work, I needed to look at the back-end and could not get much information from ICS. I even had some cases where the backend indicated a correct request and response, however ICS indicated something had gone wrong. Since ICS did not allow me access to logs or more technical debugging information, this was difficult to fix but I eventually managed by means of the proven 'trial and error' method.
You cannot edit an active Integration. This means that you will have to take measures in order to avoid downtime when a configuration changes. Maybe put something in front of ICS, make a copy of the Integration and route all traffic to the copy. Then bring the Integration down which you want to edit, make your changes, re-activate it and point back to the original endpoint. This is similar when working with a load-balancer and you need to update several nodes. The publish-subscribe pattern which is supported in ICS could also help with this.
When changing the Connection configuration in an Integration, you loose all mappings in the integration and you have to do them again (which will become troublesome when building complex Integrations). When changing a Connection, Integrations need to be reactivated (deactivated and activated) for the changes to become effective. This is of course not strange since a redeployment needs to be executed.
Many of the cloud services have a preconfigured Oracle Traffic Director. You can configure this traffic director (which contains connectivity information) from the Compute cloud service. Below you can see a screenshot from some of the security rules for my SOA-CS database and JCS instance on which SOA-CS runs.
This is not available for ICS. If you want to limit who can access your API's, you should put something in front of it. Also the username/password token which you can put on your service is hardcoded / a single username/password. You might find this also limiting and would want to attach this to a true identity store.
You have the option however to upload certificates.
Other things to look at
This is just a first tryout and by no means I completely understand the product yet. The product is quickly improving due to regular new releases. I have not looked at the API's yet or performance. Also I only tried two adapters and the strength of the product probably lies with the many other adapters which are available to integrate SaaS solutions. Also I have not looked at different integration patterns yet such as Publish and Subscribe. They might prove useful to achieve loose coupling in more complex integrations and might help to guarantee up-time, even when changing Integrations. I do think however that more complex integrations will be difficult in ICS due to lack of debugging and error handling functionality and the fact that a little change in a Connection requires you to re-do all mappings in an Integration unless you made an export before and are a bit creative with manually editing the files in the export. I have learned quite a lot about this product in a short time (about 1 day) so it is probably not too difficult to learn for a citizen developer.