If you’re writing code you should be thinking about ways to test it. This should apply even if what you’re writing is not immediately familiar as code. HP Operations Orchestration (HP OO) is an orchestration tool with a visual IDE. It’s used to create workflows by dragging and dropping operations together and then connecting them. The idea is to provide a simple interface for operations engineers to automate tasks they would otherwise perform manually. Despite the simple interface, it is still possible to create quite complex logic within these workflows. Add to this, the fact that your workflows probably connect to lots of systems, and you soon realise why you need to test the content you are creating.
Continuous Integration to the rescue
Testing Operations Orchestration content is not entirely easy. The best way to start is by creating some simple test wrapper flows around the workflows that you want to test. They should take the flow you are working on, hardcode some test inputs and check the output of the flow, the response should be “resolved” if everything worked. These are somewhere between a unit test and an integration test. Once you have these created, you can run them directly from studio to test the flow you are working on. It’s up to you how thorough you want to be with this. You’ll also want to think about setup and teardown for each flow you test.
Once you are ready to commit the workflow you’ve written, you need it to be built into a content pack and deployed to an OO central. Then you should run each test workflow to check that they work for that particular build. This gives you confidence that the flow can reach all the endpoints it needs to and that any other criteria in the test flow is met.
To automate this and turn it into a proper pipeline you’ll want to use something like Jenkins or Team City to create the builds, do the deployments and run the test workflows. To make this easier, I’ve written a command line tool (https://bitbucket.org/automationlogic/oo_client) that can build content packs, deploy them and run workflows using the OO REST API. It also has a test runner that will run all flows matching a pattern and aggregate the results. This means you’ll get a non zero exit code if any of the test flows fail. To set it up you should just create three jobs for each content pack. The first one is a build job, it should take the SVN/Git checkout and build a content pack, like this:
svn co svn://localhost/srv/svn/mmb-oo #Your CI tool will probably do this for you. cd mmb-oo/trunk/test-content/ mkdir target hpoo -a build -bp ./
The deploy job should take the created content pack and run this:
hpoo -a deploy -cp ./target/test-content-cp-2.0.1-109-SNAPSHOT.jar -c https://central.local:8443 -u admin -p admin
Finally, you can run your test flows with a job that runs this:
hpoo -a integration_test -cp test-content --filter tests/integration_tests/test_ -c https://central.local:8443 -u admin -p admin
For full examples, check out the README
Hopefully that has given you some ideas for how to speed up your development of OO content whilst ensuring that you are creating something that can be tested.