|Re: Stardust API's Deployment - Poll Data via Query API [message #1277927 is a reply to message #1277887]
||Wed, 26 March 2014 16:55
| Jan Hendrik Scheufen
Registered: October 2011
so, personally, I find it easier to deal with the Java API (via Spring Remoting), because then the code is cleaner and you can concentrate on the logic without having to deal with WS-related stuff, e.g. handling soap faults or similar.
Of course, if you use a framework like CXF which also shields those details from you or you're just more comfortable with the WS API and it saves you time, just stick with that.
One thing that I'd like to mention is that "enrichment" is a typical EAI pattern for which I tend to use Apache Camel (which ships with Stardust). I'm not 100% sure if it makes sense in this case, but you could trigger a Camel route from your monitoring code which executes the steps you need to enrich and store the data.
If the information you need to retrieve in your queries consists of process and/or activity instances, then we provide a Camel DSL for Stardust, so that you don't even have to write a Query.
Example commands for Camel route (remember that Stardust is based on a product called "IPP", therefore the "ipp:" prefix):
<!-- authenticate -->
<!-- find a process instance based on name and data -->
<!-- retrieve the entire process properties -->
Just a thought ... As I said, this depends on how your enrichment looks. But putting it in a Camel route like that allows you swap out a step with a different implementation or add steps more easily.
The Camel Component per default uses Spring Remoting under the hood. In case you're interested to learn more see here:
[Updated on: Wed, 26 March 2014 16:58]
Report message to a moderator
Powered by FUDForum
. Page generated in 0.01757 seconds