RE: {Spam?} RE: {Spam?} Activities/Steps question

Your suggestion makes sense Geeta - it is what I thought of on the way
home.
 
The key is what you said halfway through your note:  "Shark can only
know about the very next activity".  While this is very obvious, it
didn't occur to me because of my thoughts are poisoned by our poorly
designed existing system.
 
Since this is true, how the "workflow" is implemented today (assign
everything up front) with our own crude coding will not work once we
adopt Shark.
 
In a very crude solution, I could have a series of process variables
which could contain the assignments.  As my code calls the complete()
method, I could also update the assignment of the next activity by
reading the process variables.  Crude, but effective.
 
Monique suggested creating my own AssignmentManager.  This sounds a bit
more difficult, but much more elegant and flexible.  I'll have to dig
into it.
 
Thank you all for your suggestions!
 
Greg
 
 -----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Monday, July 18, 2005 5:02 PM
To: [email protected]
Subject: Re: {Spam?} RE: {Spam?} [shark] Activities/Steps question




Greg, 

thought about this some more while I was making dinner and seems like
what you have observed below: 

"However, when I call the createProcess() method, and interrogate the
WfProcess, it appears there is only one activity (and that one only
exists after the start() method has been called).  

Am I to assume there is no way to assign all of these activities to the
proper owner when the process is created and I must assign them as each
activity is completed?" 

- this *has* to be the way Shark can handle it. This is due to the old
question - how can I come up with all the activities? The simple answer:
you can't. Your particular process is linear and we may think that Shark
*ought to* be able to come up with all the activities, but this is the
case only in this particular process definition, right? In general,
given a process *instance* (which is what you have when you interrogate
it), Shark can only know about the very next activity. It is possible
that there are branches along the way later (which are dependant on data
variables which Shark cannot know about now) and so Shark cannot
possibly know what the activity isntances are other than the one after
the current activity (only one in your case).. So I would assume that
you would have to assign each activity to the proper owner only as each
(previous) activity is completed. Which should not be a problem, right?
You can just have data variables holding this info (about who owns what)
which you can fill when the process is created and then consult them to
assign the correct owner as you go along  ..Am i making sense? 

Geeta 




"Dahl, Greg (BLM) - contr" <[email protected]> 


07/18/2005 04:20 PM 


Please respond to
[email protected]



To
[email protected] 

cc

Subject
{Spam?} RE: {Spam?} [shark] Activities/Steps question

	




I thought about this Geeta. 
  
For instance - for one type of record, GroupOne is assigned StepOne and
GroupTwo is assigned StepTwo. 
But, I also have instances where GroupThree is assigned StepOne and
GroupTwo is assigned StepTwo. 
And, of course, instances where GroupOne is assigned StepOne and
GroupThree is assigned StepTwo. 
  
I've got 500 different UserGroups as it is.  The number of existing
permutations is quite large.  Right now, they're kept in a relational
database table, keyed on the proper record attributes.   
  
 If I am thinking right, this means I would have to define a different
process for each possible combination of people responsible for the
flow.  Is that right?   
  
It could be done.  It would make my code very simple because now I only
have to figure out the correct process to start and I'd be done.  Setup
would be tedious but possible.  However, the administrative maintenance
(as the users change their mind about who is responsible for what) is
the real nightmare. 
  
Perhaps I'm thinking about those "swimlanes" all wrong. 
  
Greg 
  
-----Original Message-----
From: [email protected] [mailto:[email protected]] 
Sent: Monday, July 18, 2005 3:09 PM
To: [email protected]
Subject: Re: {Spam?} [shark] Activities/Steps question


Hi Greg, 

When I create my xpdl with JaWE, I place each activity in the
"swim-lane" for the user/group/role responsible for the activity. And
Shark certainly seems to be able to pick up this info nicely.  Is there
any reason you don't/can't do the same thing? 

Geeta 



"Dahl, Greg (BLM) - contr" <[email protected]> 


07/18/2005 02:36 PM 



Please respond to
[email protected]




To
[email protected] 

cc

Subject
{Spam?} [shark] Activities/Steps question


	





Forgive me if I get the terminology wrong:

I created an XPDL document (using JAWE) that has five steps - in a
linear fashion.  Step two is always done after step one, step three
always after step two, etc.

When I _create_ the process, I already know which group should be
assigned to each step.

However, when I call the createProcess() method, and interrogate the
WfProcess, it appears there is only one activity (and that one only
exists after the start() method has been called).  

Am I to assume there is no way to assign all of these activities to the
proper owner when the process is created and I must assign them as each
activity is completed?

Thanks,
Greg
******* Confidentiality Notice *******
This email, its electronic document attachments, and the contents of its
website linkages may contain confidential health information.  This
information is intended solely for use by the individual or entity to
whom it is addressed.  If you have received this information in error,
please notify the sender immediately and arrange for the prompt
destruction of the material and any accompanying attachments.





-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


--
You receive this message as a subscriber of the [email protected]
mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws


CONFIDENTIALITY NOTICE:This email is intended solely for the person or
entity to which it is addressed and may contain confidential and/or
protected health information.  Any duplication, dissemination, action
taken in reliance upon, or other use of this information by persons or
entities other than the intended recipient is prohibited and may violate
applicable laws.  If this email has been received in error, please
notify the sender and delete the information from your system.  The
views expressed in this email are those of the sender and may not
necessarily represent the views of IntelliCare. 

-- 
This message has been scanned for viruses and 
dangerous content by  <http://www.mailscanner.info/> MailScanner, and is

believed to be clean. 
--
You receive this message as a subscriber of the [email protected]
mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws


CONFIDENTIALITY NOTICE:This email is intended solely for the person or
entity to which it is addressed and may contain confidential and/or
protected health information.  Any duplication, dissemination, action
taken in reliance upon, or other use of this information by persons or
entities other than the intended recipient is prohibited and may violate
applicable laws.  If this email has been received in error, please
notify the sender and delete the information from your system.  The
views expressed in this email are those of the sender and may not
necessarily represent the views of IntelliCare.

--
You receive this message as a subscriber of the [email protected] mailing list.
To unsubscribe: mailto:[email protected]
For general help: mailto:[email protected]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws