Hi Guys,

I'd also add option 3:

3. Call the WorkflowEngine directly (bypass XmlRpcWorkflowClient and call the 
WorkflowEngine) and its #startWorkflow method which returns a Workflow Instance 
Id.

Now, specific comments below:

> 
> I agree, the second approach is probably the way to go. Although, would it be 
> more beneficial to save and return a single 'event' ID instead of multiple 
> workflow instance IDs?

Nah, I'd say that rather than impose that as an external facing interface just 
tag the workflow (or set of workflows) with the appropriate dynMetadata coming 
in and then you can look up the workflow instance based on that metadata by 
paging through them later.

> I'm under the assumption that workflow behaves something akin to a job 
> submission system.

It's not. That's the resource manager. The workflow manager is a data flow + 
control flow system.

> This assumption may be incorrect, but it might be beneficial to just get back 
> a single unique ID for the launch of a workflow top-level event as opposed to 
> getting back a list of IDs...

I'd check out:

http://oodt.apache.org/components/maven/workflow/development/developer.html

That link has a concise description of what the WM is all about.

> 
> So perhaps within XmlRpcWorkflowManager.handleEvent, we could generate and 
> save a unique ID for the single event? This ID could be queried by a client.

I'd say that's supported by Paul's suggestion #1 below, no?

Cheers,
Chris


> 
> On Apr 25, 2011, at 1:25 PM, Ramirez, Paul M (388J) wrote:
> 
>> Hey All,
>> 
>> Thought this might be useful to the larger OODT community.
>> 
>> 
>> 
>> Hey Rishi,
>> 
>> I talked with Mike about this last week but never got back to him with a 
>> concrete answer. However, after putting some more thought into it there are 
>> 2 approaches I can think of.
>> 
>> First Approach:
>> 1) Put some type of user generated id in the metadata object that gets into 
>> the workflow instance metadata
>> 2) Page through the lists of workflow instances that the workflow manager 
>> has and identify those with your tag. Remember an event can kick off more 
>> than one workflow.
>> 3) Any that have metadata that match your user generated id are your 
>> workflow instances you're interested in.
>> 
>> Second Approach:
>> 1) Add a new method to the client and server so that list of workflow 
>> instance ids is returned
>> 
>> Looking at XmlRpcWorkflowManager.java
>> 
>> 
>>   public boolean handleEvent(String eventName, Hashtable metadata)
>>           throws RepositoryException, EngineException {
>>       LOG.log(Level.INFO<http://Level.INFO/>, "WorkflowManager: Received 
>> event: " + eventName);
>> 
>>       List workflows = null;
>> 
>>       try {
>>           workflows = repo.getWorkflowsForEvent(eventName);
>>       } catch (Exception e) {
>>           e.printStackTrace();
>>           throw new RepositoryException(
>>                   "Exception getting workflows associated with event: "
>>                           + eventName + ": Message: " + e.getMessage());
>>       }
>> 
>>       if (workflows != null) {
>>           for (Iterator i = workflows.iterator(); i.hasNext();) {
>>               Workflow w = (Workflow) i.next();
>>               LOG.log(Level.INFO<http://Level.INFO/>, "WorkflowManager: 
>> Workflow " + w.getName()
>>                       + " retrieved for event " + eventName);
>> 
>>               Metadata m = new Metadata();
>>               m.addMetadata(metadata);
>> 
>>               try {
>>                   engine.startWorkflow(w, m); // This returns a workflow 
>> instance which has an id that could be saved and returned
>>               } catch (Exception e) {
>>                   e.printStackTrace();
>>                   throw new EngineException(
>>                           "Engine exception when starting workflow: "
>>                                   + w.getName() + ": Message: "
>>                                   + e.getMessage());
>>               }
>>           }
>>           return true;
>>       } else
>>           return false;
>>   }
>> 
>> This should probably be a new method on both the client and server and 
>> should be supplied as a patch. The method would return either List<String> 
>> or List<WorkflowInstance> probably the latter but maybe someone else will 
>> chime in. Of course this would have to have the accompanying client method 
>> but it shouldn't be that big of an update.
>> 
>> My instincts would say that second approach is probably the way to go.
>> 
>> 
>> Thanks,
>> 
>> Paul
>> 
>> 
>> 
>> On Apr 25, 2011, at 11:39 AM, Verma, Rishi (317I) wrote:
>> 
>> 
>>  return ((Boolean) client
>>                   .execute("workflowmgr.handleEvent", argList))
>>                   .booleanValue();
>> 
>> Is there a way to obtain and query for a workflow 'instance ID'?
>> 
>> Thanks!
>> Rishi & Mike
>> 
>> 
> 


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Chris Mattmann, Ph.D.
Senior Computer Scientist
NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
Office: 171-266B, Mailstop: 171-246
Email: [email protected]
WWW:   http://sunset.usc.edu/~mattmann/
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
Adjunct Assistant Professor, Computer Science Department
University of Southern California, Los Angeles, CA 90089 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Reply via email to