Forum Discussion

photon's avatar
photon
Contributor
2 years ago

incorrect scenario running scheduled job using WFScenario parameter

Currently, we have a manual process that involves a user running a Load and Transform that uses a data source with a DM Sequence as its source. That sequence uses the |WFScenario| parameter.

This all works great until we try to schedule it.

I pass the scenario and the time in with a parameter at the Sequence level. The first step takes this parameter (e.g., Scenario=BudgetFinal) and creates a trigger file in the Batch folder and runs ExecuteFileHarvestBatch. The correct workflow executes but appears to be pulling its data (via that first DM Sequence/Data Source using WFScenario) from my current, user WF/POV.

I've tested this by navigating to correct WF/Scenario, then running the DM job I want to schedule and the data successfully imports. If I then navigate to a different scenario and run the same DM job again, the import fails with the error that there is no data.

I would expect the WFScenario parameter to use the scenario of the WF that is specifically calling the parameter but that doesn't appear to be the case.

Is there a fix here? Am I just using the wrong parameter?

 

Data Management
Workflow
  • photon's avatar
    photon
    2 years ago

    Alright, si.PovDataCellPk still failed but it did inspire me to check other parts of si and this solves the problem:

     

    si.WorkflowClusterPk.ScenarioKey = BRApi.Finance.Members.GetMemberId(si,DimTypeId.Scenario,scenario)
si.WorkflowClusterPk.TimeKey = BRApi.Finance.Time.GetIdFromName(si,year)
si.WorkflowClusterPk.ProfileKey = BRApi.Workflow.Metadata.GetProfile(si,wfName).UniqueID

     

    The profile key override isn't strictly necessary for the export/import part of this but there's additional downstream code that looks at the staged results and for that the WF key is relevant. I've shipped this off to my users for testing but it appears to be good for now.

     

  • JackLacava's avatar
    JackLacava
    Honored Contributor
    2 years ago

    If you're triggering this from a rule, you could try setting the POV by manipulating the SessionInfo object, changing si.PovDataCellPk.

    To be honest, I'm not entirely sure how you're executing things. Could you post your Sequence and Steps definition maybe...?

    • photon's avatar
      photon
      Contributor
      2 years ago

      Alright, si.PovDataCellPk still failed but it did inspire me to check other parts of si and this solves the problem:

       

      si.WorkflowClusterPk.ScenarioKey = BRApi.Finance.Members.GetMemberId(si,DimTypeId.Scenario,scenario)
si.WorkflowClusterPk.TimeKey = BRApi.Finance.Time.GetIdFromName(si,year)
si.WorkflowClusterPk.ProfileKey = BRApi.Workflow.Metadata.GetProfile(si,wfName).UniqueID

       

      The profile key override isn't strictly necessary for the export/import part of this but there's additional downstream code that looks at the staged results and for that the WF key is relevant. I've shipped this off to my users for testing but it appears to be good for now.

       

      • DanielWillis's avatar
        DanielWillis
        Valued Contributor
        2 years ago

        Just randomly came across this thread. I wonder if it would be safer to override the whole workflowcusterPK. E.g.,

        Dim wfClusterPK As WorkflowUnitClusterPk = brapi.Workflow.General.GetWorkflowUnitClusterPk(si,wfName,scenario,year)
si.WorkflowClusterPk = wfClusterPK

         

    • photon's avatar
      photon
      Contributor
      2 years ago

      There are two DM sequences. One is the export that is the source of the data for the data source. The second is just used to schedule/execute the workflow.

      The scheduled sequence accepts a parameter, Scenario=BudgetFinal, to determine what scenario to use for the trigger file name for and to run the harvest API call. The data export sequence is just set to use |WFScenario| and I would expect that a workflow currently importing for BudgetFinal would also cause |WFScenario| to be BudgetFinal. It's not.

      However, I've never attempted to manipulate the si object so that seems worth a try.