JavaScript - Interactive Record Locking

1 Overview

There can be scenarios in bxp software (bxp) where the queue management record distribution method is not ideal for giving out pieces of work. Instead the use of Work Lists is preferred, however they do not lock a record to your use. They could allow two users to interrogate the same record. So how to combat this situation yet still give the flexibility of a Work List, but singular delivery of the queue management engine?

The solution is to use AJAX and to work with the engine in bxp.

2 The elements

There are a few basic things that will happen on this page.

• A check to see if the record is locked.
• A locking mechanism to capture the record.
• A number of storage variables to ensure you still have the lock.

3 The Check

The first part of the process is to see if the record is locked or not. This is done using AJAX lookups i.e. the "LiveSearch" function. You do a lookup to see if the "Status" of the CDA you currently have is "Taken to process". This status is a reserved status used by the bxp engine to flag that a record is currently in use by an agent.

More information on the "LiveSearch" function can be found here JavaScript_LiveSearch

• if it is "Taken to process" then mark the record as not available to edit
• if it is not "Taken to process" then we allow editing of the record

If you want to make this check truly valid you would put the check on all data entry fields, to ensure you still have control.

4 Locking the record

You then need a function to update the record, the below would be a good starting point.

You then need to use your check again, to ensure that the record is locked to you.

If you do have the lock then you can continue, if not you'll want to remind your user that the lock attempt failed.

This second check to see if the lock has taken should compensate locking issues. [1] However for quick click you need to put compensating locking on all of the edit fields. To save having to do a look up for the entire form, you could maintain a hidden variable with a count, that if the count gets up to 3 or greater, then further checks are not necessary.

We don't increase the record count, as the Inbound process engine used with Work Lists, will auto increment the count, reset the outcome and set the current user again, when the outcomes is used and the record saved.

When the lock is clicked, it can be released by choosing an outcome and saving the record.

	if (typeof aryAjax_Settings=='undefined')
			alert('Library did not load');
	else {
		aryAjax_Settings[0] 	= 	'client_demo'; 
		aryAjax_Settings[1] 	= 	'';
		aryAjax_Settings[2] 	= 	'';
		aryAjax_Settings[3] 	= 	--intCampaign_Id--;
		aryAjax_Settings[4] 	= 	'null'; 
		aryAjax_Settings[5] 	= 	'null';
		aryAjax_Settings[13]	= 	-1;
		aryAjax_Settings[14] 	= 	'false';
		aryAjax_Settings[15] 	= 	'';
		aryAjax_Settings[16] 	= 	'dbUpdateRecord';
		aryAjax_Settings[6] 	=	'intCurrentIdOfRecordUpdated';
		aryAjax_Settings[12] 	=	'Id Of Updated Record';
		aryAjax_Settings[17] 	=	objContainingCDAId;

		aryAjax_Settings[22] 	= 	document.getElementById('intSystemGenerated_CompanyId').value;
		aryAjax_Settings[23] 	= 	document.getElementById('intSystemGenerated_UserId').value;
		aryAjax_Settings[24] 	= 	document.getElementById('intSystemGenerated_LoginKey').value;
		
		aryAjax_Settings[34] 	= 	'strCDA_X_Status,intCDA_X_StaffId';		//	Fields to update
		aryAjax_Settings[35] 	= 	'Taken to process,--intCurrentUserId--';		//	Values to update
		aryAjax_Settings[36] 	= 	'intCDA_X_Id'	;		//	Field to match on
		aryAjax_Settings[37] 	= 	 intCDA_X_Id;			//	Value to match with
		aryAjax_Settings[38] 	= 	"True";						
		
		fn_Ajax_BE_Process();
	}

5 The hidden elements

So for your locks and checks there are a number of hidden items from the form that you're going to need to access

• intCampaign_Id, the system hidden field with the current form id.
• intCDA_Id, a system hidden field with the id of the current CDA in it.

• intHidden_Count, for your loopguard on your checks mentioned in the lock function above. You need to add this.
• strHidden_CurrentStatus, you add this to store the results of the check for a lock
• intHidden_CurrentOwner, you add this to store the results of the check for a lock

6 Notes

Taken to process means that the record will show up on the incomplete records if the lock is clicked and no outcome is chosen. This also allows for closer management and use of the lock buttons, so that it is only pressed when necessary. It also allows team leads to control locks and ensure records are updated properly.

The feedback to show that the page is locked can be done a number of ways. One of the most visually appealing can be the "lightbox" approach. [2]

7 Setup process summary

The process for this section is

1. Add a button to the page in the Introduction of the page, as "Lock Record". This calls a function called fn_LockRecord();
2. Add the hidden fields as outlined in the The Hidden Elements section above.
3. Add to the onChange of every question fn_CheckLock();
4. Add to the onLoad of the form a number of functions:
   1. fn_LockRecord(); // this will attempt to lock the record to you
   2. fn_CheckLock(); // this will attempt to see has the record been locked to anyone

8 Conclusion

This is an outline suggestion as to how one might go about providing a lock on a record in a form. There are other approaches. If you would like us to help you construct this solution with you / for you, then please contact us on +353 1 429 4000 or email support@allnone.ie