Usually things will go wrong, and the system comes up with error messages which you have to decipher. A collection of errors, their source, and their solution.

Ladybug is your friend

When we debug we want details of the process we want to control. Ladybug gives a precise flow of events inside a pipeline. When a message reaches the Ibis we can follow the process step by step and see where it went wrong. By folding out the various elements of your pipeline you can see the red cross showing an error. Also when there’s no error, you can inspect the values of your variables just by clicking on them. In the example below we can see that the outputvalidation failed, probably due to a wrong stylesheet rendering. You can find ladybug in the ‘testing’ menu.






correct the typo in CreateCustomer.




realmName=”jdbc” omitted in jmsRealm tag. A nullpointer exceoption usually points at a property that you have to include in your tag.


Wrong input message

A wrong input message generates the following kind of errors:

That means that your message contains some kind of error that is detected in the validation against an xsd file. This can be tricky : “Klantnummer” is totally different from “KlantNummer” so be very consistent in your naming policy ! You can either change you xsd or the structure of your input file.


Configuration is sent but not loaded!

You are maybe too quick : Ibis4Education checks for configuration changes every minute. Go to the tab of your Ibis and press the reload button. Make sure your configurations are listed in Configuration.xml.  As a last resort you can check under “Scheduler” for the checkReload task and push the button “trigger”.

Also check in the database that your configuration is loaded. You can do that in the menu jdbc/browse tables, via the table ‘ibisconfig’. When you see your Ibis listed there with an active = ‘true’ you are okay. Use the upload time and date to confirm this.



Create your own error messages

When a pipeline has as it’s only exit a ‘success’ you will not get any other messages back to your client application. Add other exits for a server error, or for bad requests, not authorized, etc.  For example <exit path=”ServerError” state=”error” code=”500″ empty=”true” /> In your pipeline you can add forwards towards this exit :<forward name=”exception” path=”ServerError” /> Your own breakpoint code can be useful too : <exit path=”ThisBadError” state=”error” code=”999″ empty=”true” /> , and using them at the points you choose : <forward name=”exception” path=”ThisBadError” />