Finally, here is the second part of my series regarding SAP Business ByDesign Studio scripting languages…
First of all, one addition to my Part 1: Programming Languages of SAP Business ByDesign Studio. I`m sorry but I forgot to explain the message functionality in BODL (“lean exception”). Developers can define messages which can be raised out of ABSL during runtime. The message text must be defined in BODL and you can`t edit it in ABSL. The only way to add runtime information, thus, is to add parameters in BODL and set these in ABSL later. I will come back to this later in this article.
The following code snippet illustrates the definition of messages in BODL:
You have to add the keyword “raises” and the message ID for all actions for which you want to throw a message during runtime.
I will explain the functionality of ABSL based on the code snipped from my Part 1: Programming Languages of SAP Business ByDesign Studio. After writing the BODL part, you have to activate the business object and create script files for your actions and (if desired) for the BeforeSave and AfterModify events as well (for explanation of the events, please refer to the Part 1: Programming Languages of SAP Business ByDesign Studio.
Now you can start to write your ABSL coding. Here is an example:
The above listing shows the default structure of an ABSL script – Import statements at the top, followed by variable declarations and the actual script logic. All variables, including loop variables, have to be declared at the top. Variables are usually declared implicitly, either by setting the value directly in definition (cf. line 14) or by setting it later in the script (cf. lines 16 and 23). The exception illustrated in line 18 only works for structures like associations and nodes, but not for global data types.
As a consequence of the declaration of variables at the top of a script, every variable is global and must be unique within the script file.
ABSL data types are a little different from data types in BODL. For example, the BODL type “LANGUAGEINDEPENDENT_LONG_Name” corresponds to a String in ABSL and the BODL type NumericValue corresponds to a Numeric in ABSL. You might say this is not a major problem, as the mapping is performed automatically by the system. But be careful…. As described in my previous article, you need to be careful when setting a “LANGUAGEINDEPENDENT_*_Name” variable. Why? Because “LANGUAGEINDEPENDENT_SHORT_Name” is defined by a size of 10 characters. But there is no check at runtime how many characters are inserted, so you will not receive any error messages when inserting 20 characters. However, when you try to save this “LANGUAGEINDEPENDENT_SHORT_NAME” (save BO) to a DB field with only 10 characters, you will get one…
Let’s take a look at some further language elements…
ABSL offers a number of structures similar to other programming languages:
- If-else clauses
- Switch statement
- Foreach loop
I am positive I don’t have to explain if-else clauses or switch statements here on SDN 🙂
Please note that foreach is the only available loop in ABSL. There are no for or while loops available. This can be a problem for more complex algorithms, because foreach loops are designed to iterate over collections and not for anything else. So you cannot (!) do something like this:
while (counter > 10)
Currently there is no workaround available for this gap but in ByDesign Studio FP3.0, while loops will be available…so we have to wait…
Now that you know the basics, you may want to know how to get data out of existing business objects and how to manipulate such data.
For this purpose, SAP provides a number of queries. Please refer to lines 14-16 in the above listing for such a query definition. First, you have to define which query you want to use, in this case the identification query of the business object Employee. Queries differ in the numbers and types of their attributes. Note: all business objects have at least one query, namely “QueryByElements”.
After defining the query, you can declare params and you have to declare a result set (lines 15-16). Now you can add parameters to your list (line 21) – code completion will assist you. The first ingredient of the parameter is one of the attributes available in the query (in this case SearchText), followed by an “I” (include) or “E” (exclude) and a compare mode, e.g. “EQ” (equals), “GT” (greater than) or “BT” (between). Finally. The last ingredient is the value of query attribute selected in first argument. If you select BT as the compare mode, you have to add two values to the parameter definition. In order to accomplish this, ABSL provides an overloaded action. Now that you have added your parameters, you can execute your query and iterate over its result (lines 23-29).
In ByDesign Studio FP2.6, queries were the only way to create a temporary collection, but there was no way to add or delete elements (but you could use nodes to mimic persistent collections with in BODL, including adding and deleting elements). Fortunately, this gap will be closed in ByDesign Studio FP3.0.
Finally, message handling in ABSL. As I had pointed out above, you have to define the message in BODL, including the message text. Later, you can add parameters and specify the severity in ABSL:
You cannot catch the messages like you might expect from exceptions in other programming languages – messages will only appear on the user interface.
So I think that’s enough for a first overview of the ABSL features.
Next and last part of this series is about SAPRuby or rather UI-Designer programming with the ByDesign sdk…