Training tool - capacity calculation issue with Workflows

G

Hi everyone,

 

I'm gonna try to keep this as simple as possible, and hopefully someone will be able to provide some technical advice.

 

Situation: we have to develop a Training tool that allows users to register employees for different courses. I have already build a cheap and dirty version of the overall solution, which mainly consists of four lists:

- Courses type list: the user can create a course type and with a repeating section add the dates on which the course will be delivered. 

 

- Courses dates: fed by the prior list via a Nintex workflow, it contains the different course's instances (course name - date) previously created with the repeating section

 

- Registrations: the user can register employees for the different courses, using a repeating section. The output for this list  is a row that basically contains how many employees have been registered. This would act as an auxiliary list.

 

- Enrollment: again, fed by the prior list via a Nintex workflow that processes the repeating section.

 

Each course will have a certain amount of available seats, which will need to be updated each time a user makes a registration. The AvailableSeats field is contained in the Courses dates list, and it is easy to update its value each time someone enrolls employees in the Registration list: a query list , a math calculation and an update item actions and that's it (the workflow would run on the Registration list, but update the item in the Courses dates list)

 

THE ISSUE

The thing is, I am not sure of the behavior once a lot of users (50-100) begin to enroll employees. I am afraid the Nintex workflow won't be enough, as there would be a high risk of an incorrect update. This is, what happens if two users make a registration about at the same time? there's a risk both workflows start running, query the current available seats (let's say 80 seats), but then the update will go wrong, as both workflows will substract a different amount from those 80 seats, and whichever finishes the last will "win". 

 

I hope I've made myself clear. Maybe there's something I am missing and I shouldn't be worried, but would like to have some clarification/advice/opinion before moving forward with the tool development. I was thinking that maybe I could build a workflow that runs directly on the Courses dates list, and run it from the Registration list with a wf that uses a call web service action.

 

Any guidance is reallllly appreciated. Thanks a lot!

 

Regards,

Gian

3 replies

Garrett
Userlevel 6
Badge +16

Hi @gianplod 


 


There is no way to ensure the outcome when 2 workflow run at the same time.


WF1 - query balance AvailableSeats. retrieve 80


WF2 - query balance AvailableSeats. retrieve 80


WF2 - update AvailableSeats. set 79


WF1 - update AvailableSeats. set 79


 


I had a workflow that sets a sequential Running No to each application form. There were several occurrences of duplicates Running No. There is simple no way to avoid this. I have to manually correct the Running No. In the end, I scrap the the Running No and just use the List ID as the running no. There were no further issues of duplicates Running No. 


 


An alternative


Use one List for each Course Instance (Course X, Date Y, Time Z, Venue A, Room B)


Per enrollment, Add a User using Create List Item action into the List.


Get the List ID for that item. 


If the List ID is Less Than or Equals AvailableSeats (lets say 80), User is confirmed. Status = Accepted


If the List ID exceeds AvailableSeats, User is not confirmed. Instead of deleting the User, we just retain them as reserves, User is on WaitList. Status = WaitList.


 


When 2 users apply, (luck of draw when workflow runs and add user to list), whoever is ID==80 is Accepted and whoever ID==81 is on WaitList.


 


We are using SharePoint capability which wouldn't allow for 2 items with the same ID 80


 


Cheers

MegaJerk
Userlevel 5
Badge +14

This is something that Nintex struggles with, but out of the necessity of needing something similar solution (Many potential item statuses that need to inform a single central parent item) in my own environment, I might be able to help. 


 


Really I need to know a little more about what's happening during the Registration portion. Are your users creating List Items that have a Nintex Form + Repeating Section where they can enter in 'n' number of Enrollees? When they want to add more people do they edit the previous Item or create a new one? 



 


Depending on the way you're entering the info, my idea may or may not work, I just need to know a few more details about how the workflow that will run is actually be invoked.


 


If the stars align something like the solution I created here might work: https://community.nintex.com/t5/Nintex-for-SharePoint-Forum/Best-Practice-Question-Tracking-Multiple-Item-States/m-p/99891/highlight/true#M69647


 


Just know that I quite literally cannot guarantee that it works in your environment, but once I get some more details I will try to work up an example that you can follow along with. I've been meaning to do a proper write up about this method / approach for a while, so better now than never! 



 


 

G

Hi @Garrett, @MegaJerk ,


 


Thank you both for your responses.


 


@Garrett nice idea, not applicable in my case as I would end up having A LOT of lists, but I like the approach.


 


@MegaJerk I took a look at your solution and I think it is an enhanced version of the my idea regarding the use of a Call Web Service to trigger the workflow that updates the capacity directly in the list that contains all of the courses dates. We built a workflow and added a state machine to re try in case the wf is already running (for the cases in which the registrations are made at about the same time).


 


Right now, I gave it a try with some JavaScript code on the submit button, which basically makes a GET and a POST call to update the capacity in the courses dates' list. It worked fine for two simultaneous registrations, but no for more (however, given the number of people interacting with the tool, it would be REALLY unlikely to have 3 or more people SIMULTANEOUSLY clicking submit when registering employees for a course).


 


I'm still having some issues to prevent the form from uploading when the capacity is 0 or less than the number of registered employees (at submit time), but I guess there's some way of achieving so.


 


Other good idea that came up from the team, is to put every registered employee in a "Pending Approval" state, and have an "orchestrator" Site workflow running daily and calculating the new capacity by substracting each employee individually. This would also help to implement a waitlist queue.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings