07-08-2023 06:33 PM
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)"
07-10-2023 05:09 AM - edited 07-10-2023 05:59 AM
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.
07-10-2023 09:09 AM - last edited on 07-10-2023 09:21 AM by JackLacava
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
07-11-2023 09:16 AM
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.