Skip to main content
K
Kai
Newcomer
July 28, 2022

How to use business rule to push data to cube Origin "Import"

  • July 28, 2022
  • 5 replies
  • 0 views

I am trying to push some data from a sql table back to the cube. I tried to use SetDataCellsUsingUsingCsvFile and SetDataCellsUsingMemberScript. Unfortunately, both function works for the Origin Forms but not Import. Could anyone kindly provide me with a working example? Thank you

 

Kai

5 replies

D
db_pdx
Contributor
July 28, 2022

Hi Kai: your post is a bit light on details, but this feels like a red flag to me.  If you want to import data, I'd recommend using the standard Workflow (Import > Validate > Load) based approach .  You'll have the combined functionality of the Workflow itself, the Data Source rules, the Transformation Rules, and all of the audit logs that come with it.

Maybe you can explain more what you're hoping to do?

Cheers

-db

    N
    NicoleBruno
    Veteran
    July 28, 2022

    Hi Kai, 

    To db's point, the O#Import member can only be populated via the import channel in order to keep clear restrictions on manually manipulated data in OS vs uneditable data from the source. Here's what I found in the OS https://endodev.onestreamcloud.com/onestreamweb/Help/Content/Design%20and%20Reference/Workflow%20Guides/Using%20Workflow%20Profiles.htm: 

    Import Child Origin Mapping

    The Workflow Engine enforces a relationship between Import Child Profile types and the Import Member of the Origin Dimension.  This means, when loading data, the Origin Member will be forced to the value Import.

      C
      OneStream Employee
      ChristianWOneStream Employee
      OneStream Employee
      July 29, 2022

      All brapi rules like SetDataCellsUsingUsingCsvFile do write to Forms (I prefer to use SetDataCellsUsingMemberScript).

      If you want to "write" to Import with a business rule, you need to run a financial business rule (Finance Function Type: Calculate or CustomCalculate) with the restriction that you only can "write" to one dataunit at a time and you need to set isDurableCalculatedData = True to not loose the data with the next normal calculation/consolidation.

      So it isn't a load in the traditional way, but a calculation.

      K
      KaiAuthor
      Newcomer
      July 29, 2022

      Hi Christian,

      Thank you very much for your response. You mentioned a way to write to import using Business rule using Calculate or Custom Calculate with restrictions. Could you please kindly provide me with an example? This will be very helpful. Appreciate it

       

      Kai

      K
      KaiAuthor
      Newcomer
      July 29, 2022

      Thank you everyone. I know that here I am trying to let "Import" do something it is not designed to do. The business case here is that I have data store in SQL editor component. Ideally, data here will be pushed from SQL Editor to the Origin "Import" because I would like to leave Origin "Form" as another way for user to input manually. An alternative is to use another dimension such as UD, but I would not want to create a new member if not 100% necessary.

       

      Kai

      D
      db_pdx
      Contributor
      July 29, 2022

      Standard Workflows (Import > Validate > Load) can source data from any SQL table.  Consider making it a Direct Load so that it skips all of the audit log and it should be pretty fast.  It might be even easier to maintain than a BR depending on the complexity of the data.

      Edit: SQL table with Import > Validate > Load is essentially what a good number of the register based marketplace solutions do (People Planning, Capital Planning, etc.)

      K
      KaiAuthor
      Newcomer
      July 29, 2022

      Thank you! I know the example in People Planning. However, in my example, it could cause problem because import - validate - load always needs to be implemented at the very last step, because the processing bar will push all the way to the end, and completes the workflow. In my use case, user needs to save the data in the register, and then the data is supposed to go to the cube immediately. Then user need to go back and work on the register for another account, and save the data again. In other words, the work cannot be done in one saving, or it would be too much data entry in the register for one time. If I implemented the same as people planning, the workflow will be completed every time user saves data. In order to continue working on the register, user has to revert workflow to continue using register, which is very time consuming. 

       

      Thus, I am thinking of the way to push data direct to import without bothering the "import - validate- load". Hope this explains. Thank you very much db_pdx for your input.

       

      Kai

       

      K
      KaiAuthor
      Newcomer
      August 2, 2022

      Thank you! I know the example in People Planning. However, in my example, it could cause problem because import - validate - load always needs to be implemented at the very last step, because the processing bar will push all the way to the end, and completes the workflow. In my use case, user needs to save the data in the register, and then the data is supposed to go to the cube immediately. Then user need to go back and work on the register for another account, and save the data again. In other words, the work cannot be done in one saving, or it would be too much data entry in the register for one time. If I implemented the same as people planning, the workflow will be completed every time user saves data. In order to continue working on the register, user has to revert workflow to continue using register, which is very time consuming. 

       

      Thus, I am thinking of the way to push data direct to import without bothering the "import - validate- load". Hope this explains. 

      Terms & ConditionsAccessibility statement