| Stardust API's Deployment - Poll Data via Query API [message #1274467] |
Fri, 21 March 2014 10:06  |
Eclipse User |
|
|
|
Hello,
I would like to request some reference document or pointers to understand how to deploy Stardust Poll Data via Query API by creating and using a Jar or War file into the Stardust Project deployed on Tomcat Server. Extension of thread [1]
My current Status
I am able to Poll the Data via Query API, like the one given in example on the wiki [3], but the poll only works if my poll source code is in a Stardust full Project that is deployed on the Tomcat in my RAD not in a Jar or War that I can add to 'webapps' of a deployed project.
My question is to understand how to use Query API code by putting it in a Jar or War and using it in the Tomcat with a deployed Stardust Project.
Similar techniques: Data generation using SPI API's
I have been able to 'Successfully' use and deploy the BPMS SPI Monitoring API such as IProcessExecutionMonitor and others as explained by Jan in the thread [2].
I simply add the Jar to the project Your_Stardust_Project_Name\WEB-INF\lib and the Stardust Engine once deployed on my Tomcat 7 server starts generating data (in my case to a file) about activity and Process completion (as per my requirements).
I hope I was able to put forward my question in a clear manner.
I would be really grateful if you could kindly guide me though the steps that are needed to solve my question.
Thanks in advance!
Best Regards,
Kunal.
P.S.
[1] http://www.eclipse.org/forums/index.php/t/482625/
[2] http://www.eclipse.org/forums/index.php/t/551904/
[3] https://wiki.eclipse.org/Stardust/Knowledge_Base/Java_API/Process_Instance_Queries (The import files need to be updated in the Example as they are ag.carnot.workflow.* and not org.eclipse.stardust.*)
|
|
|
|
|
|
|
|
|
| Re: Stardust API's Deployment - Poll Data via Query API [message #1277927 is a reply to message #1277887] |
Wed, 26 March 2014 12:55  |
| Eclipse User |
|
|
|
Hi Kunal,
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 -->
<to uri="ipp:authenticate:setCurrent?user=motu&password=XXXX"/>
<!-- find a process instance based on name and data -->
<to uri="ipp:process:find?processId=CreditApproval&dataFilters=Customer.Id::983432::long"/>
<!-- retrieve the entire process properties -->
<to uri="ipp:process:getProperties"/>
<!-- logout-->
<to uri="ipp:authenticate:removeCurrent/>
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:
http://help.eclipse.org/kepler/topic/org.eclipse.stardust.docs.camel/html/camel/camel-ipp-component.html
Best,
Jan
[Updated on: Wed, 26 March 2014 12:58] by Moderator |
|
|
|
Powered by
FUDForum. Page generated in 0.31216 seconds
Home