Fcst - Copy of Actuals into Locked/Certified Fcst scenario via BR

[Clarke_Hair]

We have a job that leverages the Global Time and Scenario to copy Actuals over into our Fcst Scenario.  My question is around the ability of a BR to change data in a certified scenario.  From what we are finding, even if we certify the Fcst Scenario, when the rule runs and the Global period has not changed, the BR copies/updates the Fcst period with Actuals.  Part of the problem is that sometimes we have to move the period forward for our operational folks while we are still working on Fcst so the Global Fcst scenario stays the same but the period get moved.  This then creates a situation where our DM jobs update the current period (Import Origin) with $$ which throws off our Fcst.

My question is:  Is there a systematic way to prevent this or do I need to add logic in my BR to check the status of something (note: this copy is not tied to any WF's, just a general copy this to that).

Goal is that once we certify our Fcst WF's (Entities are tied to these WF's), nothing should be changed.

[TheJonG · Accepted solution]

There is not a way (that I know of) to stop BRs from running on locked or certified workflows. The below script will check workflow status and throw an error if the workflow is completed or locked.

Dim wfInfoAlloc As WorkflowInfo = BRApi.Workflow.Status.GetWorkflowStatus(si, si.WorkflowClusterPk)
								
If wfInfoAlloc.AllTasksCompleted = True Then									
     Throw (New XFUserMsgException(api.si, Nothing, Nothing, "  >>> Rule cannot be 
    executed because workflow is COMPLETED... revert workflow in order to execute"))
Else If wfInfoAlloc.Locked = True Then
     Throw (New XFUserMsgException(api.si, Nothing, Nothing, "  >>> Rule cannot be 
     executed because workflow is LOCKED!"))
End If	

Note that there is a performance impact of using the BRApi.Workflow.Status.GetWorkflowStatus call because it has to open up a database connection to the Workflow Engine. So if this rule is being kicked off by many users at the same time, you could experience some significant server strain as many database connections are opened for each instance of the rule being ran.