Shape the future of IBM!
We invite you to shape the future of IBM, including product roadmaps, by submitting ideas that matter to you the most. Here's how it works:
Post your ideas
Start by posting ideas and requests to enhance a product or service. Take a look at ideas others have posted and upvote them if they matter to you,
Post an idea
Upvote ideas that matter most to you
Get feedback from the IBM team to refine your idea
Help IBM prioritize your ideas and requests
The IBM team may need your help to refine the ideas so they may ask for more information or feedback. The offering manager team will then decide if they can begin working on your idea. If they can start during the next development cycle, they will put the idea on the priority list. Each team at IBM works on a different schedule, where some ideas can be implemented right away, others may be placed on a different schedule.
Receive notifications on the decision
Some ideas can be implemented at IBM, while others may not fit within the development plans for the product. In either case, the team will let you know as soon as possible. In some cases, we may be able to find alternatives for ideas that cannot be implemented in a reasonable time.
Please use the following category to raise ideas for these offerings for all environments (traditional on premises, containers, on cloud):
Cloud Pak for Automation - incl Business Automation Studio, Business Automation Insights
Business Automation Workflow (BAW) - incl BAW, Business Process Manager, Workstream Services, Business Performance Center, Advanced Case Management
Content and Capture Services - incl Filenet, Automation Document Processing, Daeja, Navigator, Content Collector, Enterprise Records, Business Automation Content Analyzer, Datacap, Automation Mobile Capture, Content Manager OnDemand, IBM Content Manager
Automation Decision Services (ADS) - incl ADS, Operational Decision Manager
Robotic Process Automation
Robotic Process Automation with Automation Anywhere
IBM Blueworks Live
If you encounter any issues accessing the Ideas portals, please send email describing the issue to ideasibm@us.ibm.com for resolution. For more information about IBM's Ideas program visit ibm.com/ideas.
Another use case that I want to share with IBM is one that I believe is applicable to both headless BPM applications and traditional coach BPM applications. There is the case where a user is performing a team distribution role (typically a manager) where a group of process instances would be assigned to a BPM user. This assignment process could be accomplished on an individual basis, however, from a UI it would make sense for the manager user is selecting multiple process instances to distribute across a team. The bulk API would allow for a single REST request per assignee that would be generated. Again, this should be a very common use case that bulk could support if it returned failures.
Attachment (Use case): This attachment provides the set of available actions to state matrix and corresponding state diagram to help explain the interactions we have built within BPM.
The use case is we are trying to follow a 3 step process that uses a ‘Query – Claim – Finish' sequence to lookup the task ID to perform the claim and finish to complete a task and update data values stored in the business object defined to BPM.
If since the task ID is not something we currently track at time of instance creation, we have to perform the query but this step potentially could be taken out of the sequence if start instance returned the task ID of the first human activity.
I am attaching a diagram from IIB that I believe is attached to the RFE as a better visual of what we are doing today exercising the same thing but implemented in a process loop handling bulk requests one at a time.
We are using the headless implementation of BPM so we have written our own UI with microservices that call out to IIB exposed user operations (assign, cancel, complete, unassign) via REST-enabled services. Through the UI, a user takes action on one or more process instance. The “or more” part is what would trigger the bulk scenario. So if a user assigns 10 instances from the UI, that would equate to a process loop of 10 assign requests that ultimately follow the sequence described below. If we had the bulk REST functionality implemented we could make a single call at each step in the sequence so it's still a 3 step process however, it would be only a single iteration regardless whether the user asked for 1 or 100 assign requests. The query, claim, and finish are all done via the REST API to communicate with BPM. Hopefully, this explains things to a level that makes sense.
Attachment (Use case)
Attachment (Use case)