bildwelt
E2E FORUM
E2E Bridge E2E Commerce

BPMN Process vs. User Interface Controller

E2E Forum User Interfaces BPMN Process vs. User Interface Controller

This topic contains 3 replies, has 3 voices, and was last updated by  Cyril 4 years, 3 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #629

    Christof
    Blocked

    We have a business process that contains many user interactions, e.g.

    • user authentication
    • wizard-style forms including several steps
    • upload of documents

    Between the user interactions, there are also backend interactions, e.g.

    • processing of inputs of form step 1
    • based on the inputs, an external application decides upon proceeding with step 2 or step 3

    Completion of the whole process might take several days, so it’s important to store the current process status and already populated data persistently.

    At a first glance considering the facts above, the following approach seems appropriate:

    1. modeling the whole process as BPMN  = transparent communcation basis for all stakeholders
    2. modeling the user interface mockups connected to the separate process steps
    3. deriving a UML state engine from the BPMN = allows long-running processes and transparently monitoring process state, e.g. in process dashboard
    4. derviving user interface controller / messages / bindings from the ui mockup
    5. connecting the ui service calls with the persistent state port type to send signals to the process

    However, there are certain drawbacks:

    • The UI controller and the BPMN process generally contain identical / overlapping information and need to be maintained synchronously.
    • If the UI controller expects “feedback” from the process, this needs to be done synchronously, e.g. by working with ps conversations.
    • If the UI should allow to go one step forward but also one step back, all these possible transitions need to be depicted in the BPMN process

    The drawbacks seem to make future maintenance and adaptations elaborate, that’s why I would rather tend to the following approach:

    • Within the executable BPMN process / pool, model one “high-level” user interaction step only, having a “update” transition to itself.
    • Within a non-executable BPMN pool, model the detailed user interface and backend interaction steps
    • Within the user interface controller, model any backend interactions and update the executable process using the “update” transition

    However I’m still not very happy with this approach…

    Any opinions or experiences?

     

    #638

    Marcel R.
    Blocked

    Could you add a screenshot of the process?

    #640

    Christof
    Blocked

    Attached a jpg of an example process for a flight booking, with alternating user and service tasks to illustrate the problem.

    • I think the BPMN notation describes the process nicely, is a sound discussion basis.
    • However, in the real world, I wouldn’t translate this into a persistent state engine.
    • Instead, I’d rather use a UI controller to model this – which degrades this specific BPMN process to “pure documentation”.

     

    #642

    Cyril
    Moderator

    I agree this is actually a UI process, the user tasks are the UI states and services tasks the UI transitions with services calls.

    A persisted process would be needed if you have some asynchronous tasks like “send a confirmation email one week before”  or if the user can cancel some time later.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.