Topic
  • 8 replies
  • Latest Post - ‏2012-06-20T21:28:51Z by SamiRiti
AshleyFernandes
AshleyFernandes
5 Posts

Pinned topic WPS deffers commit on initiation of Long Running Flow using EJB's initiate

‏2012-06-01T04:33:45Z |
Hi All,
Any of IBMs EJB API, eg.initiate, initiateAndClaim, sendMessage (or complete, completeAndClaim) APIs which starts long running flows/completes tasks on a Long Running Flow, reverts with a response, without committing data into WPS. So any immediate subsequent call/query, may or may not return a result depending on when WPS decides to commit the data. (eg. so an early query to fetch pending tasks may not return with any result while a latter call after say one minute may result with pending tasks) This behavior is seen when WPS BPEL flows have sub processes.PFA, a screen of the whole architecture.

Is there any IBM API which would initate a long running BPEL flow with Sub Processes and commit the data into the WPS DB and finnaly return back the result to the client? (we also require a similar API for Completing a task)

Any pointers wrt to the ones mentioned below would help us
  • Suggest/provide an API which would initiate a Long running flow and revert back a PIID only once it has committed the task data into the WPS DB. Require the same also for Complete?
  • Another alternative would be if, we could explicitly from the client program commit a WPS transaction (API).
  • Query Uncommitted Data in WPS.

Note : IBM's initiateAndClaimFirst API does not work for sub processes.

Thanks & Regards
Ashley
  • zhangyu
    zhangyu
    179 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-01T07:49:16Z  
    if you didn't have an existing ditributed transaction in place when calling wps bfm ejb, the transaction started by wps will be committed/rollback once the response/exception returns to caller. so not really understand your question.
  • zhangyu
    zhangyu
    179 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-01T07:50:52Z  
    btw, i saw there is no transactional problem with your architecture. please elaborate what's problem/errors you are facing
  • AshleyFernandes
    AshleyFernandes
    5 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-01T10:51:07Z  
    • zhangyu
    • ‏2012-06-01T07:50:52Z
    btw, i saw there is no transactional problem with your architecture. please elaborate what's problem/errors you are facing
    Hi Zhangyu,

    Thanks for your interest.Please consider this simple scenario....

    1. J2EE client calls the WPS's intiate API to start a long running BPEL flow.
    2. J2EE client then calls the WPS's Query API, to query any pending tasks (of the newly started BPEL flow with subprocesses).
    3. The result of the query is no rows found.Reason, whenever WPS BPEL flows have sub processes, the commit happens later. (ie. the initiate API returns a response, even though it has not committed the task data into the WPS database)
    4. The same query is run after one minute.....this time, it returns one row. (due to the late commit of WPS Task data into WPS Database)

    I require the first query call to return back a row.In other words, i want WPS to initiate the long running flow, commit data into its DB and then return back the response of the initiate call.Currently WPS is initiate the long running flow, returning back the response and after a period of time committing data into the WPS DB.

    Thanks & Regards
    Ashley
  • zhangyu
    zhangyu
    179 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-01T13:05:36Z  
    Hi Zhangyu,

    Thanks for your interest.Please consider this simple scenario....

    1. J2EE client calls the WPS's intiate API to start a long running BPEL flow.
    2. J2EE client then calls the WPS's Query API, to query any pending tasks (of the newly started BPEL flow with subprocesses).
    3. The result of the query is no rows found.Reason, whenever WPS BPEL flows have sub processes, the commit happens later. (ie. the initiate API returns a response, even though it has not committed the task data into the WPS database)
    4. The same query is run after one minute.....this time, it returns one row. (due to the late commit of WPS Task data into WPS Database)

    I require the first query call to return back a row.In other words, i want WPS to initiate the long running flow, commit data into its DB and then return back the response of the initiate call.Currently WPS is initiate the long running flow, returning back the response and after a period of time committing data into the WPS DB.

    Thanks & Regards
    Ashley
    ok, i understood your problem. the strange result you observed is reasonable because long running process is made up of many chained transaction and it has transaction behavior setting that can impact the transaction boundary. also if long running process invokes another service, depending on the invocation style (sync or async), the transaction boundary is also differernt.

    there are some valuable articles on this topic:
    sca transaction: http://www.ibm.com/developerworks/websphere/library/techarticles/0904_fong/0904_fong.html

    long running process: http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.websphere.bpc.612.doc/doc/bpc/cprocess_transaction_macro.html

    one more: http://www.ibm.com/developerworks/websphere/library/techarticles/0906_fasbinder/0906_fasbinder.html

    w.r.t to your specific problem, if the human task is in the invoved process (not in sub process), you can configure receive activities' transaction behavior to participant (default is commit after). if the human task is directly linked to the receive activity, you should get the task instance after the ejb call is made. if the human task is in sub process,there are many factors that will impact the transaction boundary. you may can or can't get the human task instance created after the ejb call is made (because it may be created in later transactions).

    i can help to review your business process design if you can provide the PI file.
  • AshleyFernandes
    AshleyFernandes
    5 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-04T07:18:09Z  
    • zhangyu
    • ‏2012-06-01T13:05:36Z
    ok, i understood your problem. the strange result you observed is reasonable because long running process is made up of many chained transaction and it has transaction behavior setting that can impact the transaction boundary. also if long running process invokes another service, depending on the invocation style (sync or async), the transaction boundary is also differernt.

    there are some valuable articles on this topic:
    sca transaction: http://www.ibm.com/developerworks/websphere/library/techarticles/0904_fong/0904_fong.html

    long running process: http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r1mx/index.jsp?topic=/com.ibm.websphere.bpc.612.doc/doc/bpc/cprocess_transaction_macro.html

    one more: http://www.ibm.com/developerworks/websphere/library/techarticles/0906_fasbinder/0906_fasbinder.html

    w.r.t to your specific problem, if the human task is in the invoved process (not in sub process), you can configure receive activities' transaction behavior to participant (default is commit after). if the human task is directly linked to the receive activity, you should get the task instance after the ejb call is made. if the human task is in sub process,there are many factors that will impact the transaction boundary. you may can or can't get the human task instance created after the ejb call is made (because it may be created in later transactions).

    i can help to review your business process design if you can provide the PI file.
    Hi Zhangyu,
    Appreciate your Response.You have understood the problem perfectly.

    Basically in WPS, long running flow are asynchronous in nature.Due to which it does not commit data immediately into WPS DB.
    My Business Requirement mandates me to use Sub Processes, I cannot avoid this.Also the BPEL flow is huge.

    Effectively Single Person workflow pattern fits my requirements perfectly, http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html. But that does not work for Sub Processes.

    Had read the links given by you earlier, but none describe how to call long running flows or Sub Processes in a single transaction.

    In my case
    Process 1-> Sub Process 2-> Sub Process 3-> Sub Process 4-> Sub Process 5 (contains human task)
    The problem here is Sub Process 5's invocation will be ASYNCHRONOUS since Long running flows (Human Task flow) are ASYNCHRONOUS in nature.

    Is there anyway i can configure the above to participate in a single transaction?

    Thanks & Regards
    Ashley
  • zhangyu
    zhangyu
    179 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-04T12:51:05Z  
    Hi Zhangyu,
    Appreciate your Response.You have understood the problem perfectly.

    Basically in WPS, long running flow are asynchronous in nature.Due to which it does not commit data immediately into WPS DB.
    My Business Requirement mandates me to use Sub Processes, I cannot avoid this.Also the BPEL flow is huge.

    Effectively Single Person workflow pattern fits my requirements perfectly, http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html. But that does not work for Sub Processes.

    Had read the links given by you earlier, but none describe how to call long running flows or Sub Processes in a single transaction.

    In my case
    Process 1-> Sub Process 2-> Sub Process 3-> Sub Process 4-> Sub Process 5 (contains human task)
    The problem here is Sub Process 5's invocation will be ASYNCHRONOUS since Long running flows (Human Task flow) are ASYNCHRONOUS in nature.

    Is there anyway i can configure the above to participate in a single transaction?

    Thanks & Regards
    Ashley
    because sub-process 5 is long running, it can only be invoked asynchronously. which means the request has to be in-queue first and then another transaction can pick up the request from queue and then start a new process instance. so there is no way to make it joining your calling transaction.

    why you want to get the task instance ready (or ready to be querable) after the ejb call complete? can you have other design alternative? like using api event handler to callback you once the task is created?
  • AshleyFernandes
    AshleyFernandes
    5 Posts

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-04T14:42:48Z  
    • zhangyu
    • ‏2012-06-04T12:51:05Z
    because sub-process 5 is long running, it can only be invoked asynchronously. which means the request has to be in-queue first and then another transaction can pick up the request from queue and then start a new process instance. so there is no way to make it joining your calling transaction.

    why you want to get the task instance ready (or ready to be querable) after the ejb call complete? can you have other design alternative? like using api event handler to callback you once the task is created?
    Hi Zhangyu,

    Thanks again for your suggestions.

    To answer your question "why you want to get the task instance ready (or ready to be querable) after the ejb call complete?"

    Our Business Requirement is that "if the user initiating/completing the BPEL flow/task is a potential owner of the task, the task should be auto claimed with current user credentials". Now in the Custom properties of the task we store the screen name of the task.That screen needs to be rendered to the user synchronously.Hence we query for pending task and try to derived the screen name from that.We have a CUSTOM UI in the J2EE client which will then render that Screen.

    Basically this is the similar to Single Person Workflow pattern.(http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html)
    (User does not have to go to dashboard and claim task)

    So User will synchronously see first task screen, he would then enter data, complete the task (using WPS complete API & query) and then immediately see the second task screen...etc.The flow would be smooth.

    Therefore, even the api event handler would not help, since that is a call back, and we would not be able to render a smooth screen flow.

    Thanks & Regards
    Ashley
  • SamiRiti
    SamiRiti
    1 Post

    Re: WPS deffers commit on initiation of Long Running Flow using EJB's initiate

    ‏2012-06-20T21:28:51Z  
    Hi Zhangyu,

    Thanks again for your suggestions.

    To answer your question "why you want to get the task instance ready (or ready to be querable) after the ejb call complete?"

    Our Business Requirement is that "if the user initiating/completing the BPEL flow/task is a potential owner of the task, the task should be auto claimed with current user credentials". Now in the Custom properties of the task we store the screen name of the task.That screen needs to be rendered to the user synchronously.Hence we query for pending task and try to derived the screen name from that.We have a CUSTOM UI in the J2EE client which will then render that Screen.

    Basically this is the similar to Single Person Workflow pattern.(http://publib.boulder.ibm.com/bpcsamp/humanTaskFeatures/singlePersonWorkflow.html)
    (User does not have to go to dashboard and claim task)

    So User will synchronously see first task screen, he would then enter data, complete the task (using WPS complete API & query) and then immediately see the second task screen...etc.The flow would be smooth.

    Therefore, even the api event handler would not help, since that is a call back, and we would not be able to render a smooth screen flow.

    Thanks & Regards
    Ashley
    Hi Ashley,

    This is an interesting problem. Did you resolve it? or did you change your design to work around the issue?
    Please update with your findings.

    I'm looking into an asynchronous invoke scenario and your problem is somewhat similar to mine.

    Thanks
    Raghu