Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • The goal of this presentation is demonstrating the use of jBPM in a real-life application.
    The application that is used, is a proof-of-concept which was developped for one of our customers.
  • This is an application architecture which is typically found in companies which have used ICT for quite some time time.
    In this example, there is a large mainframe machine on which both legacy programs (upper right) and more modern programs (left) are running.
    Some applications are implemented as terminal programs (the application runs entirely on the server, lower right) and some are outsidethe mainframe, but they are using some functionality offered by the applications running on the mainframe.
    Commons for this “organically grown” architectures is a cobweb of dependent applications.
    Also notice that most of the workflow management logic (WFM) is scattered accross different applications.
  • These are the requirements for the proof-of-concept
  • This slide explains why we chose jBPM to implement the workflow logic
  • Before we start building the proof-of-concept, we first had to make sure that jBPM was “fast enough”
  • For simple sequential actions, the performance of jBPM is very good.
    The actions don’t have any logic in them (so we only measure the jBPM overhead).
    Every action has a different handler class, so that no caching can happen between the nodes of the same process.
    For these setups, we see that jBPM is very fast, what is to be expected since only some Hibernate calls are necessary.
  • Parallel execution paths are more difficult, but as shown on the slide the average running time is in line of expectation (which is very good).
  • This business process is a real-life example.
    The measurement was done using a report generator thread and a users-mimicing thread so the measuring went automatic.
    There is an overhead of these threads, but the average running time of 3 ms shows that it is minimal.
  • The core functionality of an ESB is “routing’.
    In reality, an ESB also has other functionality (transformation, indexation …)
    Basically this is sending a message to a given destination, using a specific protocol.
    The application that sends the message however, does not know this protocol (altough it is possible).
  • Change the mailbox with an ESB and the destination with another server/application and the story remains the same.
    The link on the bottom of the slide is done by a collegue (he is a committer of Jboss ESB).
  • The next slides give a graphical overview of the proof-of-concept.
    This is important to understand what will be shown in the demo movie on the end.
    To start, we have an application which constantly generates XML reports
  • These XML reports are sent to a Mule ESB using the low-level TCP protocol.
  • On the ESB, the XML message is transformed using XSLT (the data that is not needed is thrown away).
    The XML report is now sent to a JMS queue which is running on a Jboss server
  • On the same Jboss server, an EJB 3 MDB (Message Driven Bean) is running.
    This MDB takes messages from the JMS queue, parses the XML report and calls operations on the BPM serviceaccording to the information that is contained in the XML.
    The BPM service is implemented using the EJB3 Stateless Session Beans technology.
    This service is in fact a wrapper around the jBPM process, provinding entry/exit methods for this process (=signal methods, data retrieval methods).
  • Graphical animation of the proof-of-concept
  • Since we used the EJB 3 technology, we can cluster (scaling/high availability/fault tolerance) some Jboss servers to cope with high loads/SLA’s
  • To use SeeWhy, we have to sent an event to the SeeWhy event queue.
    This is easiliy done by using a custom class and attaching it to a jBPM node.
    The logic in the class will construct the event and sent it to the event queue.
  • Do

    1. 1. Do & Don’ts of BPM The Full Stack 13/03/2008 Joram Barrez - Dolmen
    2. 2. About  Software engineer at Dolmen Computer Applications  Using jBPM from Monday to Friday • Before january ’08  business processes on a small scale • Since january ’08, in a team of 3 people  building a large scale back-end using jBPM for process orchestration in a departement of the Flemish governement  Other fields of interest: • Agile development & (J)Ruby on Rails 29/01/15 ı 2
    3. 3. Goals  jBPM in some real-life action  Demonstration use case: PoC “jBPM orchestration” • Revitalization of mainframe architecture • PoC built to show feasability of project • Using some “cool” technologies (jBPM, ESB, EJB3, …) 29/01/15 ı 3
    4. 4. Content  Customer Requirements  JBPM Performance  Proof of Concept  BI/BAM  Demo 29/01/15 ı 4
    5. 5. 29/01/15 ı 5 Typical architecture
    6. 6. Requirements  Every application talks directly to its dependent applications • Mediation required to keep it manageable  Workflow logic is scattered across different applications • Centralisation needed  Reporting functionality is a must  It must be “fast enough” 29/01/15 ı 6
    7. 7. Why jBPM?  Previous experience  Embeddable • jBPM is “Yet Another Java Library” • jBPM can be used in any application (web, desktop, enterprise, …) on any database  Openness • Extremely extensible, what often is needed in business processes  Convenient for developers 29/01/15 ı 7
    8. 8. Content  Customer Requirements  JBPM Performance  Proof of Concept  BI/BAM  Demo 29/01/15 ı 8
    9. 9. jBPM Performance  We knew jBPM could tackle the workflow requirements  But is it “fast enough”? • Simple measurement used (e.g. no dedicated server) • 2500 runs of an automated jBPM process (jpdl 3.2.2) • Timings are average between start en stop time of the processes 29/01/15 ı 9 • Intel Core Duo 2 Ghz • 2 GB DDR2 RAM • 5400 rpm SATA HD • MySQL 5.0.45 Database
    10. 10. Some performance numbers (sequential) 29/01/15 ı 10 2 ms 2 ms 3 ms 5-6 ms Non-optimized Hibernate config: 16 ms! From 1.800.000 processes/hour  225 000 processes/hour
    11. 11. Some performance numbers 29/01/15 ı 11 5 ms 12 ms
    12. 12. 29/01/15 ı 12 Realistic business process: Handling a hospital report 3 ms New Report created Check Report type Automatic checking Some reports need manual verification Complete & archive report Remove report
    13. 13. Content  Customer Requirements  JBPM Performance  Proof of Concept  BI/BAM  Demo 29/01/15 ı 13
    14. 14. Proof of Concept (PoC)  Goal: build a small scale application that proofs the feasibility of the project • But easily can be mapped to a larger scale  Only one business process (“Handling a hospital report”)  Only two applications need communication • Report generator • Client application 29/01/15 ı 14
    15. 15. Application mediation  Problem: applications talk to each other directly, resulting in a cobweb of dependent applications • Enterprise Application Integration (EAI) problem • Topic on its own  Solution (for this PoC) • Enterprise Service Bus (ESB) 29/01/15 ı 15
    16. 16. What is an ESB? (without getting too technical)  Best comparison: mailbox 29/01/15 ı 16 Destination Protocol? “ROUTING” Don’t care, as Long as the message Is delivered
    17. 17. What is an ESB? (without getting too technical) 29/01/15 ı 17 Destination Protocol? “ROUTING” Don’t care, as Long as the message Is delivered TCP/IP SOAP(Webservice) JMS Products - Mule ESB (customer pref) - BEA Aqualogic - JBoss ESB*  SOA platform (inc. jBPM) * by Johan Kumps Advantage: applications only need to communicate with the ESB. They don’t need to use the ‘language’ of the destination anymore
    18. 18. 29/01/15 ı 18 Automatic Report Generation (XML) Proof-of-Concept overview
    19. 19. 29/01/15 ı 19 Proof-of-Concept overview Automatic Report Generation (XML) TCP MULE ESB
    20. 20. 29/01/15 ı 20 Proof-of-Concept overview Automatic Report Generation (XML) TCP TRANSFORMATION (XSLT) JMS MESSAGE MULE ESB JMS QUEUE
    21. 21. 29/01/15 ı 21 Proof-of-Concept overview Automatic Report Generation (XML) TCP TRANSFORMATION (XSLT) JMS MESSAGE JMS QUEUE EJB 3 MDB BPM Service (EJB 3 SLSB) MULE ESB
    22. 22. 29/01/15 ı 22 Proof-of-Concept overview Automatic Report Generation TCP TRANSFORMATION (XSLT) JMS MESSAGE JMS QUEUE EJB 3 MDB BPM Service (EJB 3 SLSB) MULE ESB
    23. 23. 29/01/15 ı 23
    24. 24. Content  Customer Requirements  JBPM Performance  Proof of Concept  BI/BAM  Demo 29/01/15 ı 24
    25. 25. Business Intelligence (BI) / Business Activity Monitoring (BAM)  BI ~ BAM • BAM  real-time monitoring/analysing metrics • BI  historical monitoring/analysing metrics • e.g. stock trade  buy/sell according to metrics  Extracting extra business information for taking “business decisions” • Simple example • Car repair  Availability of car history (malfunctions,…)  Better judgement when fixing the car 29/01/15 ı 25
    26. 26.  BI/BAM is an “art” • Tailoring to business is always needed • Research field on its own (even academical) • Data mining, OLAP, KPI, data warehousing, slice/dice analysis, ETL, …  Managers BI/BAM 29/01/15 ı 26 Business Intelligence (BI) / Business Activity Monitoring (BAM) “What you can’t measure, you can’t manage”
    27. 27. BI/BAM & jBPM  BI/BAM often integrated in BPM products  jBPM does not offer such functionality • Discussions about BI/BAM and jBPM can be tracked online, so it will be only a matter of time (hopefully)  So, why should we choose jBPM if BI/BAM is missing? • BI/BAM is extremely business-specific, so there will always be need for custom implementations • Openness of jBPM allows extremely business-specific BI/BAM, which could be impossible with pre-made BI/BAM solutions 29/01/15 ı 27
    28. 28. PoC: BAM with SeeWhy*  Young & enthousiastic, UK based software company  Extremely well documented (hundreds of pages) • 74 pages “SeeWhy with jBPM”  SeeWhy Community/Enterprise Edition • Realtime metrics, real time alerts, real time actions 29/01/15 ı 28 *
    29. 29. SeeWhy workings 29/01/15 ı 29 Event Calculations/ Aggregations Event Queue (JMS) e.g. Show the average number Of reports processed the last hour
    30. 30. Combining jBPM & SeeWhy 29/01/15 ı 30 Send an event to the queue on the SeeWhy server
    31. 31. Business Intelligence with jBPM  All historical data is stored in the database by the jBPM engine • So, BI is a matter of writing “the right queries”  PoC • Simple BI app (JRuby on Rails) 29/01/15 ı 31
    32. 32. PoC : Complete picture 29/01/15 ı 32 29/01/15 ı 32 Report Generation (XML) TCP TRANSFORMATION (XSLT) JMS MESSAGE JMS QUEUE EJB 3 MDB BPM Service (EJB 3 SLSB) BAM BI
    33. 33. 29/01/15 ı 33 DEMO TIME
    34. 34. Lessons learned  jBPM allows us to implement a wide range of business processes, since we have the power of Java at disposal  Business analysts aren’t fond of jBPM at first encounter • Building business processes is not a matter of drag-and-drop! • Business processes can’t be built without programmatic logic! • Transactions, performance, …  BI/BAM sells! • Defining a basic BI/BAM framework for jBPM 29/01/15 ı 34
    35. 35. 29/01/15 ı 35