Topic
  • 7 replies
  • Latest Post - ‏2012-12-17T22:56:20Z by jmac_EmeriCon
RhettWhaley
RhettWhaley
40 Posts

Pinned topic Query process instances via REST-API

‏2012-12-06T20:44:17Z |
Can anyone suggest what the best way to query process instances associated with a specific BPD would be using the REST-API? The closest thing I can find is the Process API - Process Query Entity List, but frankly it seems quite cumbersome and requires you to create a saved search first.

All I want is give me a list of process instances for BPD XYZ.

Doing this with the JS-API is very straightforward, but so far I'm not finding the same with the REST-API.

Thanks,
Rhett
Updated on 2012-12-17T22:56:20Z at 2012-12-17T22:56:20Z by jmac_EmeriCon
  • jmac_EmeriCon
    jmac_EmeriCon
    279 Posts

    Re: Query process instances via REST-API

    ‏2012-12-06T21:11:42Z  
    You need to use the Search. Something like this

    http://localhost:9080/rest/bpm/wle/v1/search/query?columns=instanceName,bpdName&condition=bpdName%7CEquals%7CTest%20Stuff&organization=byInstance

    In this case I am asking for the instanceName and bpdName to be returned and I am looking for BPDs with the name "Test Stuff"

    Before encoding the condition looked like this
    bpdName|Equals|TestStuff

    GOOD LUCK


    _______________________________________________________________________

    John McDonald

    EmeriCon, LLC
  • RhettWhaley
    RhettWhaley
    40 Posts

    Re: Query process instances via REST-API

    ‏2012-12-06T22:37:34Z  
    You need to use the Search. Something like this

    http://localhost:9080/rest/bpm/wle/v1/search/query?columns=instanceName,bpdName&condition=bpdName%7CEquals%7CTest%20Stuff&organization=byInstance

    In this case I am asking for the instanceName and bpdName to be returned and I am looking for BPDs with the name "Test Stuff"

    Before encoding the condition looked like this
    bpdName|Equals|TestStuff

    GOOD LUCK


    _______________________________________________________________________

    John McDonald

    EmeriCon, LLC
    Yes I've used the REST search API before but unfortunately it won't work in this case. The search API is "task based" and as such will only work in querying for tasks that the user making the call owns. I don't wants tasks for a specific user, I want process instances.
    So far JS-API 1 - REST-API 0
  • jmac_EmeriCon
    jmac_EmeriCon
    279 Posts

    Re: Query process instances via REST-API

    ‏2012-12-06T23:09:02Z  
    Yes I've used the REST search API before but unfortunately it won't work in this case. The search API is "task based" and as such will only work in querying for tasks that the user making the call owns. I don't wants tasks for a specific user, I want process instances.
    So far JS-API 1 - REST-API 0
    Sorry I should read more closely. The only way to do this is the kludgey way you already know. I do know that there is an RFE to open up the REST API, but I do not think it made the cut for 801.

    John


    _______________________________________________________________________

    John McDonald

    EmeriCon, LLC
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Query process instances via REST-API

    ‏2012-12-12T16:36:39Z  
    Sorry I should read more closely. The only way to do this is the kludgey way you already know. I do know that there is an RFE to open up the REST API, but I do not think it made the cut for 801.

    John


    _______________________________________________________________________

    John McDonald

    EmeriCon, LLC
    The problem with "Opening up" the REST API is that the REST API is available to every single person with a valid BPM login. Some companies have very strict rules about who can see the task and instance data associated with them. For example think of an HR discipline procedure that is implemented in BPM. If the REST API allowed you to simply issue a query "Give me back all the instances of the Discipline Procedure" then I could know who is in trouble with HR even if I'm not supposed to know that. I may even be able to tell what they did and the discussions in the process flow.

    If you don't like that example think of giving out bonuses. Or processing salary increases.

    The JS API doesn't have this restriciton because a developer needs to choose to expose the features of the JS API to an end user. An end user cannot, all on their own, issue a JS API call on the server.

    Now an argument can be made that what is/is not available in the REST API should be configurable on a per process/activity basis. Or maybe even on a process instance basis. While this would provide some nice flexibility, it is also going to add yet another set of tabs somewhere in the Process Designer UI that only 5% of the PD users are going to ever need or understand why they want to go there. I like the current approach of the REST API being fairly locked down, with a developer being able to expose additional functionality at their own risk.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
  • kolban
    kolban
    3316 Posts

    Re: Query process instances via REST-API

    ‏2012-12-12T17:02:29Z  
    The problem with "Opening up" the REST API is that the REST API is available to every single person with a valid BPM login. Some companies have very strict rules about who can see the task and instance data associated with them. For example think of an HR discipline procedure that is implemented in BPM. If the REST API allowed you to simply issue a query "Give me back all the instances of the Discipline Procedure" then I could know who is in trouble with HR even if I'm not supposed to know that. I may even be able to tell what they did and the discussions in the process flow.

    If you don't like that example think of giving out bonuses. Or processing salary increases.

    The JS API doesn't have this restriciton because a developer needs to choose to expose the features of the JS API to an end user. An end user cannot, all on their own, issue a JS API call on the server.

    Now an argument can be made that what is/is not available in the REST API should be configurable on a per process/activity basis. Or maybe even on a process instance basis. While this would provide some nice flexibility, it is also going to add yet another set of tabs somewhere in the Process Designer UI that only 5% of the PD users are going to ever need or understand why they want to go there. I like the current approach of the REST API being fairly locked down, with a developer being able to expose additional functionality at their own risk.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
    The old IBM WPS product provided access controls by task and process. When a task or process was defined (in the development tooling or the admin console), one could name a group/set of users for the following categories:

    o Potential Owners
    o Editors
    o Readers
    o Administrators

    When a query was made, your authentication was checked such that the information returned was a function of which (if any) category you belonged to.

    • Potential Owners - Could claim an item from the work queue/start a process. Could also complete the task.
    • Readers - Could look at the data associated with an existing task/process but could not interact with it
    • Editors - Could claim an item from the work queue, make changes to the data of the task ... but could not complete it
    • Administrators - Full authority including the ability to re-assign the task to others.

    The default settings were "none for anyone".

    Neil
  • SystemAdmin
    SystemAdmin
    7615 Posts

    Re: Query process instances via REST-API

    ‏2012-12-17T22:07:25Z  
    • kolban
    • ‏2012-12-12T17:02:29Z
    The old IBM WPS product provided access controls by task and process. When a task or process was defined (in the development tooling or the admin console), one could name a group/set of users for the following categories:

    o Potential Owners
    o Editors
    o Readers
    o Administrators

    When a query was made, your authentication was checked such that the information returned was a function of which (if any) category you belonged to.

    • Potential Owners - Could claim an item from the work queue/start a process. Could also complete the task.
    • Readers - Could look at the data associated with an existing task/process but could not interact with it
    • Editors - Could claim an item from the work queue, make changes to the data of the task ... but could not complete it
    • Administrators - Full authority including the ability to re-assign the task to others.

    The default settings were "none for anyone".

    Neil
    Right. I'm not saying this can't be done, I'm just saying I'm worried about what the implementation will do to the UI. There already are so many different checkboxes, drop downs, widgets, etc. in the current product that many of our less experienced users get lost. Given that the features people want can be accessed if a developer wants to make them available, I'm worried what adding even more UI complexity to the BPMN model will do.

    I'm not saying that this wouldn't help some use cases, but if a developer really wanted to, they could today create a UI for all of these. Some of it would be annoying, especially promotion because we'd likely need a custom SOR for this, but it could be done. The question becomes what this really does for the BPM product. I'm already concerned that the 8.0 Coach View have basically moved us from "A business user can create the base UI for playback one." to a world where even experienced developers need to spend a few weeks grasping how to make everything work. Sure the new UI is much more powerful, but we have left behind or at least significantly degraded the experience for on of the constiuencies.

    So yes, this could be done. We can have another tab added to the 8 we already have for each task, but I fear that it is likely just to confuse more than aid end users. Additionally I've found over the years that all of these "simple" things customers want really are not all that simple when you wind up getting into the details that the real end users want, it can be very difficult to get the right level of functionality.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
  • jmac_EmeriCon
    jmac_EmeriCon
    279 Posts

    Re: Query process instances via REST-API

    ‏2012-12-17T22:56:20Z  
    Right. I'm not saying this can't be done, I'm just saying I'm worried about what the implementation will do to the UI. There already are so many different checkboxes, drop downs, widgets, etc. in the current product that many of our less experienced users get lost. Given that the features people want can be accessed if a developer wants to make them available, I'm worried what adding even more UI complexity to the BPMN model will do.

    I'm not saying that this wouldn't help some use cases, but if a developer really wanted to, they could today create a UI for all of these. Some of it would be annoying, especially promotion because we'd likely need a custom SOR for this, but it could be done. The question becomes what this really does for the BPM product. I'm already concerned that the 8.0 Coach View have basically moved us from "A business user can create the base UI for playback one." to a world where even experienced developers need to spend a few weeks grasping how to make everything work. Sure the new UI is much more powerful, but we have left behind or at least significantly degraded the experience for on of the constiuencies.

    So yes, this could be done. We can have another tab added to the 8 we already have for each task, but I fear that it is likely just to confuse more than aid end users. Additionally I've found over the years that all of these "simple" things customers want really are not all that simple when you wind up getting into the details that the real end users want, it can be very difficult to get the right level of functionality.

    Andrew Paier | Director of Special Operations | BP3 Global, Inc. www.bp-3.com
    This is a little "off topic" from the original question but...

    Andrew said:
    
    I
    'm already concerned that the 8.0 Coach View have basically moved us from  
    "A business user can create the base UI for playback one." to a world where even experienced developers need to spend a few weeks grasping how to make everything work.
    


    I couldn't agree more.

    John

    _______________________________________________________________________

    John McDonald

    EmeriCon, LLC