Block Resource

Blocks the access to a resource.

Command availability: IBM RPA SaaS and IBM RPA on premises

Description

This command creates an internal queue, in which each request to the same lock is allocated. When the lock is released, the next request locks it again. You can view and release active locks on the IBM RPA Control Center. For more information, see Active locks.

Script syntax

IBM RPA's proprietary script language has a syntax similar to other programming languages. The script syntax defines the command's syntax in the script file. You can work with this syntax in IBM RPA Studio's Script mode.

waitLock --global(Boolean) --name(String) [--timeout(TimeSpan)] (Boolean)=success

Dependencies

You must terminate the scope of this command with the Unlock Feature command.
You need two or more Bot Runtime to run scripts concurrently.

Input parameter

The following table displays the list of input parameters available in this command. In the table, you can see the parameter name when working in IBM RPA Studio's Script mode and its Designer mode equivalent label.

Designer mode label	Script mode name	Required	Accepted variable types	Description
Global	`global`	`Required`	`Boolean`	Enable to create a lock that is accessible to every machine that runs in the same IBM RPA environment. If you don't enable it, the lock is created only on the source machine.
Name	`name`	`Required`	`Text`	The name of the lock.
Timeout	`timeout`	`Optional`	`Time Span`, `Number`, `Text`	The maximum waiting time to keep verifying whether a specified lock is available. The default timeout is 5 seconds. You can also use the Set Timeout command to define a default timeout to the script.

Output parameter

Designer mode label	Script mode name	Accepted variable types	Description
Success	`success`	`Boolean`	Returns `True` if it creates the lock, or `False` otherwise.

Example

The following code example demonstrates how to lock a resource and trying to access it while it is locked. The LogMessageLock creates a sample lock. The Block Resource command blocks access to the resource twice, and the second request is blocked by the first lock. The first lock ends after the Unlock Feature command runs.

defVar --name successfullyEnteringLock --type Boolean
defVar --name lockName --type String
// Assigns the lock name to 'LogMessageLock'.
setVar --name "${lockName}" --value LogMessageLock
// Create a lock to the resources into your scope. It create a global lock to these resources.
waitLock --global  --name "${lockName}" --timeout "00:00:52" successfullyEnteringLock=success
	// Logs the message to state if it enter the lock.
	logMessage --message "Success to enter the \"${lockName}\" lock for the first time: ${successfullyEnteringLock}" --type "Info"
	// Tries to create a new lock to 'LockMessage' before the Unlock Feature command releases it. In this case, it isn't possible because the 'LogMessageLock' still locked.
	waitLock --global  --name "${lockName}" --timeout "00:00:52" successfullyEnteringLock=success
		// Logs the message to state if it enter the lock.
		logMessage --message "Trying to access the \"${lockName}\" lock." --type "Info"
		// Unlock the lock.
	release
	// Logs the message to state if it enter the lock.
	logMessage --message "Success to enter the \"${lockName}\" lock for the second time: ${successfullyEnteringLock}" --type "Info"
	// Unlock the lock.	
release

Limitations

For IBM RPA on premises environments only: This command might not work properly on Redis version 3.0.504. For more information, see Redis causes a wrong behavior for Block Semaphore and Block Resource commands.