Process design guide

Before you create a new process, make a rough plan that covers the main tasks of the process. This plan can be, for example, a flow chart of the process that is written on a sheet of paper. The subsequent sample describes a process that copies data from an OLAP cube into another OLAP cube on the same server:

Parameters:
- The process requires a connection to the OLAP.
- If not all the data should be copied, the process might require a parameter that describes what to copy. For example, the year and the version must be copied.
Store the name of the source cube in a variable.
Store the name of the target cube in a variable.
Create a data area representing the data to be copied from the source cube.
Loop through the data area values.
In the loop, transform the values, if required.
Retrieve the coordinates from the current value that is processed and define the coordinates in the target cube. Consider what to do when the cubes have different dimensions.
Write the value to the target cube.

This list explains general design recommendations and rules:

Use variables when the same value should be used in different places. For example, a process should manage data in an OLAP cube for a specific company. Define a string variable that holds the company name or an OLAPElement variable that holds the company dimension element. Use this wherever required.
Although a process might be specific for a single purpose or a specific part of data, avoid hardcoded statements. Often you can make a process more generic. For example, a process converts the currency EUR into USD. The process should not use these elements as strings, that is, "EUR" or "USD" in every place. Instead create a variable at the beginning of the process and use it where required. You can change the values later and it helps to understand the process. You can avoid typos when you specify text only once. If a string literal contains a typo, you might not even detected it, if it is still a valid name. If you misspell a variable name, the Application Engine recognizes this immediately.
Think modular! Do not create processes that are too large. They are harder to understand the more they grow. Try to identify parts of your planned process that do the same or similar tasks. If you identify such parts, check if you can turn them into separate processes that you can use in the process to define. If you cannot extract these parts, try to make them more general and then turn them into a process.
If in the beginning it is not clear that a process can be separated reasonably into several sub-processes, design the process top-down. After it works and has been tested, think about refactoring. Try to find sub-processes that can be extracted to achieve smaller processes.
When you work with OLAP or SQL databases, minimize the number of connections. Avoid creating connections. Pass them as parameters to the process as often as possible.
When you pass OLAP or SQL connections to a process, do never close the connection there. Always close the connection in the process that has created it.
Processes can fail. Thus, if you include processes, ensure that the calling process is notified about any problems that happen in the called process. For example, return a Boolean value that indicates whether the called process has been successfully completed.
Before calling a function, ensure that all arguments are valid. For example, a function requires a string as parameter whose value must be a valid element name of an OLAP dimension. Ensure that the function is not called with an empty element name. This can be achieved through a conditional statement: "If the value is empty, then display a message and do not call the function respectively process".
Always clean up, especially if a process fails. If a process changes data and fails, consider what might be the status of that data. If this data must be cleaned up to avoid issues, at least notify the user about the tasks that must be performed. Add some sort of cleanup functionality that does this automatically.