Human-centric means there are some features that are particularly
important like management of swim-lanes, group task queues, individual
user task queues and a dynamically rendered website that allows
end-users (accountants, lawyers, clerks, etc) to interact with process
instances (with supervisor override capability). The website/console
alone requires about 30+% of the jBPM's teams current resources.
With our current ESB+jBPM integration we should be able to orchestrate a
single "process" between multiple ESB-hosted services and humans.
Consider this scenario:
1- An order is received via FTP
2- Order is routed to a validator
3- Order is routed to a transformer
4- Order is over $500 and therefore must be sent to a group task queue
(the order processing team)
5- Simultaneously an async credit check request for the customer on the
order header is made
6- Process goes to sleep and awaits a response from the order processing
team and the credit check
7- Once the credit check returns the process is now only waiting on the
order processing team
8- Every 2 hours an alert is sent out to the order processing team to
let them know that this order is getting old
9- Sally (a member of the order processing team) picks up the order from
the group queue and moves it to her own queue
10- She visually inspects the order (nicely transformed by step 3) and
visually inspects the credit report. While the customers credit score
from Dun and Bradstreet is somewhat poor, the customer has excellent
payment history with our business therefore Sally makes this additional
note on the record and pushes it from her queue to her supervisors
(additional approval required).
11- Her supervisor is currently out on vacation
12- Her supervisor's supervisor is covering these tasks and logs into to
finish the order
13- Now that all approvals are secured the order is routed to the
approach fulfillment team
14-Parts of the order require service activation (e.g. this is an order
for a new cell phone hardware and services) so those line-items are
split off and routed to the appropriate team - that team's queue is
updated to reflect the needed work (e.g. some services require the
dispatch of field workers)
15-Parts of the order require multiple warehouses to be notified and
used (e.g. one line-item is for a phone from warehouse A, another
line-item is for an blue tooth earbud from warehouse B) both warehouses
respond with real shipping costs (note customer has already been quoted
so this is just to offset the real book keeping)
16-Various email alerts are collected and properly organized and sent
out to concerned parties (e.g. the person who initiated the order is
notified that it has shipped)
17- Once all parties report in that there part of the order has been
fulfilled then accounting is alerted, the executive dashboard is
updated, etc)
My ESB+jBPM should allow me to see this process laid out visually.
Allow me to make ad-hoc process changes to both process instances that
are "above" the current change (altering step 14 for all new process
instances and process instances living prior to step 14). Allow me to
have complete visibility into how "long" something is taking at any
given step (so I can fire my order processing team). Allow me to
understand who/what is perform optimally (number of orders processed,
complexity of orders, warehouse A team is rocking along, etc). Assuming
this end-to-end process involves various 3rd parties (e.g. partners who
fulfill parts of the process), legacy systems (e.g mainframe customer
history system) and you still want a robust, easily reconfigurable
solution - well that is the promise of SOA for the enterprise.
Tom Fennelly wrote:
Excuse my ignorance, but why exactly do they differentiate between
the
different types of orchestration (human, service etc)? I'd have just
imagined it all as being event-centric, with whatever triggers (??)
the event as being somewhat secondary. Where does that fall down??
Burr Sutter wrote:
> jBPM 4.0 isn't due until late Q1/early Q2 2008. If we had specific
> requirements we might be able to get the jBPM team focused on a
> deliverable between now and and then but the challenge for jBPM is
> focus: human-centric BPM/workflow or service-centric orchestration.
> Bill Burke wrote:
>> Huh? I'm confused on exactly what 4.2 is. Mark told me that it
>> should basically be in maintenance mode and only one person was
>> going to be maintaining it while the rest of the team focused on 5.0.
>>
>> Better integration, not a single repository.
>>
>> Burr Sutter wrote:
>>> What is your timeframe for this concept?
>>> I don't believe there are enough bodies to throw at jBPM 3.3/3.4
>>> and ESB 4.2 to get them both out the door by June 2007 to bring
>>> those different worlds closely in-line. Are you proposing a single
>>> repository/single codebase or simply looking for better integration?
>>> Burr
>>>
>>> Bill Burke wrote:
>>>>
>>>>
>>>> Bill Burke wrote:
>>>>>
>>>>>
>>>>> Burr Sutter wrote:
>>>>>> The "cons" for jBPM-based orchestration:
>>>>>> - Does require learning of jPDL and jBPM actions. This is not a
>>>>>> trivial undertaking.
>>>>>
>>>>> This is a relevant issue, but I think we can refactor base jbpm
>>>>> to handle the simple usecases.
>>>>>
>>>>>
>>>>>> - It requires lots of setup & configuration for jBPM such as
>>>>>> getting the database configured correctly and Hibernate mapped
>>>>>> correctly. This is not well documented and involves some heavy
>>>>>> lifting on the part of the user. It is improving but does have
>>>>>> a real learning curve.
>>>>>>
>>>>>
>>>>> I think this is an irrelevant issue. This can be fixed. ESB 4.0
>>>>> release had the same problems.
>>>>>
>>>>
>>>> Let me expand on this. Burr, we have to stop thinking of other
>>>> JEMS projects like black boxes.
>>>>
>>>> a) Its all open source
>>>> b) We all work for the same company
>>>> c) jBPM team is under Mark anyways
>>>>
>>>> We need to foster cross-contributors.
>>>>
>>>> Bill
>>>>
>>>
>>
>
> _______________________________________________
> esb-dev mailing list
> esb-dev(a)lists.jboss.org
>
https://lists.jboss.org/mailman/listinfo/esb-dev