With the upgrade to 1808 we have finally enabled “Single Persistency” also for Custom Business Objects within SAP Cloud for Customer.
What does that mean?
If we speak of Single Persistency now it is clear, that before 1808 we had more than one persistency.
The primary persistency is the one defined by the Business Object (BO) itself. The secondary persistency was used by our Fast Search Infrastructure (FSI) executing queries in a performant manner.
But there where issues keeping this secondary persistency in sync with the data in the primary persistency of the business objects.
Who is the one who never ever had such an issue?
Furthermore, as this secondary persistency was optimized for search there were conversions of the data from the secondary persistency required or even a read access of the primary persistency.
From now on FSI will access the data in primary persistency of the business objects direct. Therefore, the query execution incl. the return of the result is faster than ever.
How did we do that?
Single Persistency means that the data which is searched by the FSI is the same data which is stored from the business object and also the same data which is returned by any retrieve.
This means the definition of the node must fit to the definition of the data base tables.
Remember this phrase.
Why wasn’t that the case?
I am sure you all know (and dislike) this message:
This message was raised for every character-based data type with no length limitation because the definition was replaced on the data base by CHAR255.
This is gone now. We are using on the data base level the definition of the GDT.
You are now able to store (theoretically) unlimited amount of characters in all those data types!!!
But nothing is for free.
What are the limitations?
As the definition of the node matches the definition of the data base table some restriction which are previously only enforced on the data base are now part of the runtime.
One is that not all GDTs are freed from the length restriction (Identifiers, see below) and the other is the usage of the unlimited GDTs.
Queries
Together with the message about the length restriction in the data base there was and is another message
This restriction is – as the definition of the node matches the definition of the data base table – now enforced in the runtime. It is now the real unlimited GDT which is used, and all data bases have their issues searching on such a data type.
You will now get a dump if you are using an element typed by such a GDT in the predefined queries QueryByElement.
These queries were originally – because of the kind of their definition – only meant to be used for test reasons (as they are restricted to their own node and only a general, not optimized implementation is available). But I know they are commonly used.
The solution for this issue is to use “real” queries defined by the Query Builder. For those queries we overcome the data base issues and treat the elements special so even a wildcard search is possible. Simply create a query below the original node, include all fields of the node, and use this query instead of the QueryByElement.
Identifiers
Because of the special way identifiers are persisted on the data base they are still restricted to CHAR255.
As the definition of the node matches the definition of the data base table this restriction is not only valid on the data base, but also in the runtime. This means the resp. element or variable is not capable to contain more than 255 characters.
In general, you will nothing lose as the persistency had previously already cut of the data for such an identifier.
Be honest: Did you ever needed an identifier longer than 255 chars?
The only case we found where a longer identifier may be really required is if this is an Uniform Resource Identifier (URI) pointing to an address in the internet like the WebURI listed in the message above.
Be aware that even here restrictions exist like the Microsoft Explorer has a maximum supported length for URIs of 2083 characters.
As these elements are cut off in the runtime it will no longer be possible to build longer WebURIs in the scripting and handing them over to the UI or Web Services or other consumers.
For such cases we defined an UNLIMITED_WebURI which will be shipped with the HotFix Collection 2.
We suggest using it in the BO definition together with the annotation Transient because this identifier shall not be used in queries like all other unlimited data types.
This element will get a special treatment, so it will not be cut off in the runtime. But of course, it will dump if used in a QueryByElement.
Summary
With the Single Persistency the query execution is faster, you can store strings longer than 255 chars, but those elements will dump if they are used in QueryByElements. The solution is to define queries with the Query Builder.
The restriction of 255 characters stays for identifiers, now even in the runtime. If you need a longer WebURI use the UNLIMITED_WebURI (available from HFC 2 onwards).
HTH,
Horst
PS: As I am no longer supporting the Partner Development Infrastructure this would be my last blog for the tag SAP Cloud Applications Studio.
I will no longer monitor the tag regularly but will still answer questions raised direct on my name.
- SAP Managed Tags:
5 Comments
