Script logic – Passing values from Excel to Script logic

Business Scenario:

Execute script logic from a Data Manager (DM) Package passing parameters for:

1. Text substitution

2. Dimension selection

Purpose:

To document my own findings and experience on this topic which might assist you to be more effective in finding your own solution. Perhaps it might also invoke those more technical to add to the discussion and close the knowledge gaps we as functional consultants struggle with in the field.

Reference (Data Manager help documentation):

http://help.sap.com/saphelp_bpc70/helpdata/en/af/36a94e9af0436c959b16baabb1a248/frameset.htm

Overview of DM package and interface:

1. When setting up the DM package the interface to BW is ALWAYS by means of a BW process chain

2. The script language in the DM package is being executed on the client machine in the front-end while the script logic (.lgf) is being executed as part of the process chain on the BW server in the backend. These are two separate concepts with two separate syntaxes.

3. The DM script language reserved words are fairly limited and can be viewed as the parameter list which is displayed when you press “MODIFY SCRIPT”

4. The values from this part of the DM script are processed in the process chain under “MODIFY DYNAMICALLY” and bearing in mind that the parameters may not be relevant depending on the content of the process chain. In this discussion we are focussing on the /CPMB/IC_DATA process chain for executing script logic. Effectively providing a user interface to UJKT.

5. When we double-click the process chain variant, “RUN LOGIC” in this case, we find the list of fields which can be populated and recognise some as standard values set by the DM “MODIFY SCRIPT” language. This list would differ between process chains and some values may not be mandatory.

6. If we revert our attention back to the DM script language then we see that setting these values requires the use of the TASK function. The script is by default populated with the constant variables e.g. %USER% (refer to help documentation for complete list)

PROMPT(SELECTINPUT,,,,”%ENTITY_DIM%,%CATEGORY_DIM%,%CURRENCY_DIM%,%TIME_DIM%”)

PROMPT(TEXT,%PROMPT_VAR1%, “Text input”, , ,)

INFO(%EQU%,”=”)

INFO(%TAB%,;)

TASK(/CPMB/ICDATA_LOGIC,SUSER,%USER%)

TASK(/CPMB/ICDATA_LOGIC,SAPPSET,%APPSET%)

TASK(/CPMB/ICDATA_LOGIC,SAPP,%APP%)

TASK(/CPMB/ICDATA_LOGIC,SELECTION,%SELECTION%)

TASK(/CPMB/ICDATA_LOGIC,REPLACEPARAM,VAR1%EQU%%PROMPT_VAR1%)

TASK(/CPMB/ICDATA_LOGIC,LOGICFILENAME,BPC_LOGIC.LGF)

7. SELECTION

The standard syntax for prompting a user for dimension input is: PROMPT(SELECTINPUT, [variable], [second variable], [label], [dimensions])

The default prompt for user input of the standard dimensions (E/C/R/T) is: PROMPT(SELECTINPUT,,,,”%ENTITY_DIM%,%CATEGORY_DIM%,%CURRENCY_DIM%,%TIME_DIM%”). Firstly notice the absence of the second parameter for [variable] but if you refer to the help doc. you will see that when omitted the default value of %SELECTION% is used.

You could therefore override or add to the prompt your own dimension(s), add a personal variable and set the SELECTION property e.g.

PROMPT(SELECTINPUT,%MYVAR%,,”Time”,”TIME”) and TASK(/CPMB/ICDATA_LOGIC,SELECTION,%MYVAR%)

Also note that the use of the “%” for denoting variables is optional and purely used out of convention for readability.

The net effect of these two lines of syntax is to dynamically set what you would otherwise have hard-coded in script logic as an *XDIM_MEMBERSET function. For completeness sake you would therefore EXCLUDE any dimensions from *XDIM_MEMBERSET scoping that you have passed using the SELECTION property.

Also note that it is not possible to “hand-shake” the selection set created by your user input dialog prompt variable (DM variable) and your script logic file variables. The DM variable contains multiple dimensions each with multiple selections so your script logic has no ability to “unravel” these sets into usable script logic variables. Rather think of the SELECTION property as a *XDIM_MEMBERSET statement sent from DM. Managing individual values must be done using *WHEN functions or other.

You can check your scoping via the SELECTION property in two ways after the script logic has been executed and you review the log file (DM View status):

a) The Package log will confirm the values of the user inputs against the DM variable.

b) The selection part of the log file will show you the resolved result of the exact full scope i.e. the combination of the user selections passed by SELECTION and the *XDIM scope.

8. REPLACEPARAM

REPLACEPARAM is the property used to pass a TEXT string from DM to script logic whether this is collected via a dialog prompt such as PROMPT(TEXT… or not. Receiving this value into the script logic file requires the same parameter value enclosed in “$” as we are fairly familiar with.

9. Conclusion

Having this basic understanding of how the interface works should better assist you in finding functional solutions for typical interface issues.

Typical functional requirements may be to:

a) Use the current context selection to drive script logic. (Context / Current view available in BADi but not in DM to pass as a parameter)

b) Limit the dialog box selections for end users (Use security settings)

c) Have the REPLACEPARAM functionality for a single selection but based on a dimension selection. (not possible)

d) Assign dimension selection to text variable in DM. (Not possible)