Everything you need to know about the new compiler

In this blog I’ll talk about the new compiler for .bo and .xbo files, which is available as of version February 2013 (1302). It’s actually been around since version November 2012 (1211) for the SAP Customer OnDemand solution, which explains why the compiler version is 1211 and not 1302. If you’ve created a new solution in 1302, you’ve probably already noticed that the syntax for business objects has changed slightly. Even though the changed syntax is documented in the What’s New section of the online help, it’s worth exploring the technical background a bit deeper before I explain how the different compiler versions influence your daily work.

Why a new compiler?

Some of you might remember that we introduced a new compiler for .absl files back in release FP3.5. We moved the compiler from the studio into the cloud backend to ensure the correct sequence when activating all files for a solution. After this move, the .bo/.xbo files were the only files for which the compiler was still performing major work in the studio. This could have led to situations in which not all dependencies were detected correctly, even when activating an entire solution. The old compiler used to run in the studio before any other file was activated in the cloud backend. This meant it could stumble over an entity that wasn’t active yet, for example, a self-defined code data type that is used by a business object node element. With the new compiler, the activation of .bo and .xbo files is carried out entirely by the cloud backend.

Apart from improving the activation sequence, the new compiler uses a new persistency layer. The persistency layer is that part of the business object runtime that takes care of loading and saving business object data from and to the database. This frees you from writing SQL statements and worrying about transaction handling and locking. The new persistency layer is prepared to make use of the advantages of the HANA database, and provides for better performance and shorter activation times.

What’s changed?

The most visible change is the new syntax for multiplicity. You now express multiplicities by using the following syntax: [<lower boundary>,<upper boundary>], e.g.: [0,1], [0,n], [1,1], and [1,n], instead of [0..1], [0..n],[1..1],[1..n].

Another change concerns the syntax of associations. The path expression that denotes the target node after the to keyword no longer includes the complete composition path to the target business node. Instead it just contains the name of the target business object followed by the name of the target business object node.

Here’s an example of the new syntax:

  businessobject Target
  {
    …

    node Sub[0,1] // was [0..1] before
    {
      …
      node SubItem[0,n] // was [0..n] before
      {
        …
      }
    }
  }

  businessobject Source
  {
    …

        // previously this had to be written as …to Target.Sub.SubItem;
    association ToItem to Target.SubItem;
  }

Last but not least, the new compiler is more restrictive with regards to data types allowed for alternative keys. The old compiler allowed for almost any data type. Even types of unrestricted length such as Identifier or LANGUAGEINDEPENDENT_Text were allowed, although the database does not support key fields longer than 255 characters. Values longer than 255 characters were either truncated or led to a dump. The new compiler forces you to use data types with restricted length, such as ID (60) or LANGUAGEINDEPENDENT_MEDIUM_Text (40) if the element is marked as alternative key. For node elements that are not marked as alternative keys, you can still use data types with unrestricted length. However, be aware that you cannot store values longer than 255 characters either.

A change that is not visible for you is that the new compiler creates new database tables with a different layout. Just changing the compiler and adapting the source files to the new syntax would mean that existing data stored in the old tables is lost. A tool that allows you to migrate existing solutions or templates to the new compiler version is being developed for a later version. It will take care of adapting the source files, changing the compiler version, and copying the business object data to the new database tables. Till then, existing solutions and templates have to stay with the old compiler.

What do you have to consider in version 1302?

For new solutions and templates, the new compiler is automatically active. As I’ve explained before, solutions and templates that have been created in FP 4.0 or earlier cannot make use of the new compiler right now in version 1302 since data migration is required. Whether a solution or template uses the new or old compiler can easily be detected by checking its Compiler Version property (the property display has been enhanced accordingly with SP level #14 of the studio). A property value of 1302 / – indicates that the old compiler is used, whereas 1302 / 1211 is the value for the new compiler (see the screenshot below for an example). You still might want to copy existing source files to a newly created solution. If so, you have to take care of the changed syntax and you will need to adapt your business object definitions after copying them to the new solution. For example, if you import an existing template that has been successfully compiled with the old compiler, your .bo files still use the old syntax. After importing the files of the template into a new solution, the activation of the business objects will fail. You need to manually adapt the multiplicity and the associations in order to successfully activate the solution. Data migration is not required in this scenario since you are just copying source files when importing a template.

It’s time to summarize: There are only a few changes introduced with the new compiler that will affect your business object definitions. However, because of changes to the persistency layer ’under the hood’, at the moment you can’t just switch your existing solutions or templates to the new compiler.