Tags
apiary, apiary.io, Boomerang, Citizen Integrator, Cloud, mockable, mockable.io, mocking, OIC - ICS, Oracle, REST, SOAP, SoapUI, testing, WSDL
We’ve been developing the example integrations to go with book on ICS and have encountered some interesting challenges for the Citizen Integrator (CI) when using an iPaaS (integration Platform as a Service). To say it in non techno speak someone wanting to plumb system together without needing to be equipped and have the skills of a developer and just using the cloud. One such example is SOAP API testing, before connecting live systems together even a CI will probably want to check that you have mapped the data correctly – important when you’ve potentially got functions and repeating structures in the mapping. To go back to my old analogy that tools for a CI like ICS are the same as Excel to ERP. Then like when creating formulas in a spreadsheet you’re going to plumb in some numbers and check the formula’s results before using in anger.
So far so obvious, the fun comes not when you’re wanting to simulate the source event coming into the tool – this can be done through a raft of utilities from Chrome Browser extensions such as Boomerang, SoapUI for example. Things become a lot more challenging when comes when you want the integration output to go to a mock SOAP API. The choices available are limited, and pretty much come down to:
- If you’re lucky you might be able to connect to a test instance of the target service. SalesForce offers a sandbox instance for example to those with a production instance of SalesForce.
- However sandbox/test instances are less likely for ‘in house’ solutions or products offered as an on premise solution unless there happens to be active development on the solution taking place.
- Ideally a mocking tool is the route to go – but only 1 option in this space appears to be available for SOAP called mockable.io
- Other than mockable you’re into using locally installed software and things get messy as it means getting the outbound web traffic routed to your own machine and then use something like MockServer (there is a great article about this tool by my book co-author Robert van Molken here). The chances are unless the network & security manager(s) are good friends or you like messing with your home network it isn’t going to happen.
- The final option is instantiating an IaaS platform such as Amazon (AWS Free Developer intro scheme to keep your cost down) or perhaps Oracle IaaS, although I’d suggest this is a fairly expensive route to enable the testing of an integration, not to mention the effort to setup things to run the test.
With REST services things are somewhat easier, as there is a lot more tools geared to helping the design of APIs, testing them and critically providing a proxy based framework to enable monetisation. For example Apiary.io can create a test harness for you. Others such as Apigee, also offer such abilities. Apiary offers a trial account and we’ll be hearing a lot more about Apiary in the near future. There is a possible work around, which is to create test integrations that map the SOAP content into a REST service (Apigee offers such a capability) but with certain constraints you could also do this within ICS itself. But we’ll look at such options within the book (can’t go without to money shot 😀 ).
This of course has only looked at the conventional use of SOAP, if you need to work with a SOAP interface that makes use of the more advanced WS-* extensions such as Reliable Messaging then things come pretty serious, and I’m afraid today you’re going to need to resort to development, and I suspect you’ll not escape that in the future either.
You must be logged in to post a comment.