Use Workflow Event Handler to unlock a workflow

[MZ]

It appears we can not use workflow event handler to automate an activity which has the same event operation type. Anyone has similar experience?

We need to automatically unlock a workflow when a sibling workflow is been manually unlocked. We wrote the rule under the BREventOperationType.Workflow.WorkflowUnlock event. But the process always fail with the below error. The same code will work if we changed it to run from the BREventOperationType.Workflow.WorkflowLock event. It seems to me we can not trigger same type of events.

"The underlying connection was closed: An unexpected error occurred on a receive. Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. An existing connection was forcibly closed by the remote host (Socket Error Number 10054)"

[JackLacava]

Unfortunately, when doing something like that there is always a strong chance of ending up in a never-ending loop: a command firing an event which invokes the same command which fires an event which invokes the same command etc etc etc. Some configurations (like yours) can detect that and abort the operation (or rather: restart the Onestream server after forcibly closing existing connections), others will remain stuck potentially forever.

If you post your code, we can have a look at where the dragons could potentially be, but chances are that this should go through Support to get some recommendations on how to deal with this problem.

Edit: thinking about this again: in past situations, when customers wanted finely-tuned control on locking, the logic was usually implemented on the Certify action of a specific profile (with auto-locking set to False in Application Properties). This should drastically reduce the chance of accidentally getting stuck in a loop.

[MZ]

Thanks Jack. I did create a ticket with support on this issue. Below is the code. If I change the operation type from WindowUnlock to WindowLock, everything works. However, our requirement is to unlock a sibling workflow when another workflow is manually unlocked. I am working with client to see whether we can twist the manually triggering event a bit.

Case Is = BREventOperationType.Workflow.WorkflowUnlock
If (args.IsBeforeEvent = True) 
	Dim wfProfileInfo As WorkflowProfileInfo = BRApi.Workflow.Metadata.GetProfile(si, _
		si.WorkflowClusterPk.ProfileKey)
	Dim wfProfileName As String = wfProfileInfo.Name
	Dim scenarioName As String = BRApi.Finance.Members.GetMemberName(si, _
		dimtype.Scenario.Id, si.WorkflowClusterPk.ScenarioKey)
	Dim timeName As String = BRApi.Finance.Members.GetMemberName(si, _
		dimtype.Time.Id, si.WorkflowClusterPk.TimeKey)

	If wfProfileName.XFContainsIgnoreCase("Import_TB") or _
			wfProfileName.XFContainsIgnoreCase("Flux Forms") Then
		Dim wfSiblingProfileInfoList As List(Of WorkflowProfileInfo) = _
			BRApi.Workflow.Metadata.GetRelatives(si, _
				si.WorkflowClusterPk, _
				WorkflowProfileRelativeTypes.Siblings, _
				workflowProfileTypes.AllProfiles)

		For Each wfSiblingProfileInfo As WorkflowProfileInfo In wfSiblingProfileInfoList
			If wfSiblingProfileInfo.Name.XFContainsIgnoreCase("Accounting Close Certification") Then
				Dim wfSiblingClusterPk As WorkflowUnitClusterPk = _
					BRApi.Workflow.General.GetWorkflowUnitClusterPk(si, _
						wfSiblingProfileInfo.Name,scenarioName, timeName)
				Dim wfInfo As WorkflowInfo = BRApi.Workflow.Status.GetWorkflowStatus(si, _
					wfSiblingClusterPk, True)
				If (wfInfo.Locked = True) Then
					BRApi.Workflow.Locking.UnlockWorkflowUnit(si, wfSiblingClusterPk)
				End If
			End If
		Next
	End If
End If

[MZ]

No response from support yet. On your edited comments, we started from there. The codes work fine if triggered by certification status. It just hang when triggering event and operation type are the same. I will take it as not recommended for now. Thanks.