[jbpm-dev] Human Task Module API and DataStructures Proposed changes

Mauricio Salatino salaboy at gmail.com
Wed Jun 27 14:17:08 EDT 2012 

Thanks Maciej for the questions. I've included comments between the bullets

"Mauricio, couple of questions at the very beginning to understand
correctly your proposal:

   - Q: how does task def service applies to process interactions - when
   task definition will be deployed?
   A: I was trying to not think about the process engine for exposing a
   Human Task Interactions APIs, but I understand your question. Right now
   inside our HTWorkItems we are calling the taskClient.add method which in
   fact is doing a deploy and an instantiation of a task based on the WorkItem
   params map. This parameters map is created based on the userTask defined in
   a process and its internal data mappings. That's from one side.
   With the form builder, what can be done right now is to "decorate" a
   userTask from a business process and define a form based on it. So
   basically we do something like: pick a process, get all the userTasks and
   for each task we end up with a TaskForm.def this TaskForm.def can be
   associated with a TaskDefinition, instead with a TaskInstance, promoting
   reusability as much as we can.
   If we have this TaskDefService, we can make both: the WorkItemHandlers
   and the Form builder to consume the same information and reuse that as much
   as we can. We can include the process designer in the loop and make the
   Company Tasks Definitions available for the editor, so the user when want
   to place a new UserTask inside their process, can choose from a list of
   presets instead of filling all the mappings, user assignments, presentation
   details, notifications settings, etc.

   - Q: delegation service - since that is on task def level - what about
   sharing this information on concurrent task instances since based on the
   same definition expressions can be evaluated to different values
   A: Yes that's the idea. In the static information we can have an
   expresion, in that case the expresion will be evaluated with the
   TaskInstance context and the result  will be placed in the task instance
   context, the task def information will not be changed, so it can be safely
   shared between instances. All the taskDef related structures should contain
   "templating" information which means something for the company. All the
   runtime status will be kept in the task instances. Think about TaskDef,
   DelegationsDef, NotificationDef, as shortcuts for the users to not define
   everything each time that they want to instantiate a task.

   - Q:how is this going to be configured - per service or will there be a
   configuration service as well
   A: good question, we can add this topic for our board session :) I'm not
   a CDI expert, but based on what I've being reading, you can provide a
   default set of services that will be automatically instantiated and
   injected, and then you can provide alternatives. If the user doesn't want
   the default settings he can defined the alternatives via a vary basic
   configuration file. Using CDI qualifiers we can, with a pair of
   annotations, define which set implementations (1 configuration) do we want
   for our whole set of services.



Would be really nice to see how this is going to be utilized from following
perspectives:

   - Q: process engine - how process engine will interact with human task
   services
   A: This should not be a problem of this module, and I think that this
   can be considered as an integration problem, so it can be
   fixed with an specialized framework such as switchyard and/or camel.
   I've being reading about the CDI support for them.. and
   I think that we can go in that way.
   The Callbacks/Listener Service is intended to store information about
   the Task Owners and their interest to be notified about a tasks events. We
   need to think about this a little bit more, because the Process Engine is
   not the Task Owner of a TaskInstance that has being created by a business
   process instance. The business process instance is the owner of that task
   in that case, so we will need to keep a reference from that process
   instance inside this service. When I say, reference I mean a business key,
   an ID, an endpoint or something to be able to notify the interested ones.
   - Q: task client - how to access tasks and to perform operations on them"
   A: via the TaskInstanceService, its the same as our TaskClient right
   now. (but restricted for TaskInstances and TaskInstancesQueries, not add,
   not Comments, not attachments, not notifications)



Cheers


On Wed, Jun 27, 2012 at 1:02 PM, Mauricio Salatino <salaboy at gmail.com>wrote:

> Hi guys,
> I'm back with more wiki pages. I was thinking about how to improve the
> Human Task Module and I came back with this wiki page
> that shows some proposals.
> The main idea behind the proposal is to modularize as much as we can the
> features provided by the human task module. I've also included
> into the proposal the concept of TaskDefinition which will allow us to add
> a nice integration with the form builder (in modeling and in runtime
> phases).
>
> I'm trying to move towards CDI to leverage all the mechanisms provided by
> the framework and the fact that exposing CDI beans across different
> platforms is extremely easy these days.
>
> https://community.jboss.org/wiki/HumanTaskAPIAndDataStructuresProposal
>
> I understand that the changes proposed in the wiki looks quite heavy, but
> I do believe that we can fit the current code base into that structure
> without loosing functionality.
>
>
> The document is showing APIs and Data Structures only. i think that we can
> assume that all the services implementation will represent simple stateless
> services which will
> insert and read information from a database, so architecturally speaking
> from that perspective the service implementations should be straight
> forward.
>
> I will be filling the Data Structure Sections briefly, but I would like to
> share the main concepts with you guys to gather feedback, as always.
>
> Cheers
>
> --
>  - MyJourney @ http://salaboy.wordpress.com
>  - Co-Founder @ http://www.jugargentina.org
>  - Co-Founder @ http://www.jbug.com.ar
>
>  - Salatino "Salaboy" Mauricio -
>
>


-- 
 - MyJourney @ http://salaboy.wordpress.com
 - Co-Founder @ http://www.jugargentina.org
 - Co-Founder @ http://www.jbug.com.ar

 - Salatino "Salaboy" Mauricio -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/jbpm-dev/attachments/20120627/c61e0b22/attachment.html

More information about the jbpm-dev mailing list