Table of Contents ... | ... Table of Code Examples |
- | 02: Interpreter, integration, structures and filtering >> |
To answer the question in the header at the very beginning, here comes a quote, raised some time ago after the first part of of development was done:
BPath is a new way to access BOL objects, which allows data / object access controlled by a dynamic, XPATH-like character string.
The initial request is very simple. Dynamic access to SAPs BOL/Genil Layer. Something that evaluates requests such as
"../AddressRelation[@MAIN="X"]/EmailAddressRelation[@BUSINESS="X"]/@EMAILADR".
Something like XPath for XML data. Some of the concepts were taken over, some didn't fit, and somehow the topic got its own life.
Well, these statements are still valid, with two remarks: The "own life" expressed in the statement got us already pretty far away from the origins. And with the latest enhancements it is possible to attach BPath to other frameworks also, not only to BOL. But since we should begin at the beginning and anyway only one other "driver" (which allows access to internal tables) is developed as of now, above "definition" remains to be fine for the moment.
My name is Jürgen Gatter, at the time of development I was part of the CRM UI Framework team (which turned into a TIP Core UI framwork team nowadays). With this blog here I want to showcase the feasibilities of an interpreted computer language developed over the past years within our team, which is called BPath and is available with WEBCUIF 7.0 EhP1. More exactly it is the starting point to a blog series covering the features of BPath, as for today we only discuss the fundamentals and ideas behind.
The beginning of the development was nearly as simple as expressed in the quote above. BOL should be enriched with a feature allowing to access the data in an XPath-like manner returning either a Business Collection or the data itself. So let us first take a look on the question to which extend we can compare XML data and Business objects:
Even though the comparison with XPath is very good to illustrate the startup, we will leave these grounds already in lesson 2 or 3. So I will no more point to similarities and differences with XPath from here.
Enuff theory, let us try out some BPath statements, even though you still do not know how to apply them - that's one of the topics of the next lesson. Just some remarks in advance to sketch the environment:
So, here comes the examples:
*
Code Example 1: *, fetching the attribute structure
The "shortest BPath statement which does something". Well ok, it is not the shortest BPath statement of all, since the emtpy statement is also a valid statement. But - surprise - the empty statement does nothing.
The '*' is a bit overloaded in BPath, it is used as multiply operator, and as we have it here, as "get it all"-operator. And 'all' means the complete attribute structure. If your statement was fired from a Business Object, the query returns the attribute structure from the respective object. If it was executed from a Business Collection, it returns the attribute structure of the first found object in the collection.
@CITYTO
Code Example 2: @attr, fetching an attribute
CITYTO is one of the attributes in the attribute structure, and exactly this attribute is returned (correctly typed) from the first object. As you might notice, the usage of the @-symbol is similar to XPath.
./@CARRID
Code Example 3, ./ , relation to myself
We are nearing ourselves to a different topic, the usage of pathes. The first is the path to the object itself, doing not much, but making the code slightly more readable.
SearchResFlightRel/FlightBookRel/*
Code Example 4, Relations
This examples uses two relations to reach the object we finally retrieve all attributes from. The first relation brings us from the Query Result Object to the root object, whereas the second relation brings us to the UIFBook object dealing with the bookings. Note that FlightBookRel is a 1:n relation, so even if we are starting from a business object, the entity which we are working on is now a collection. But still, only the first entity is returned.
As in XPath the slash is used as separator. Unfortunately this turned out to be a problem in our case, since the slash might be used within relation or attribute names also. This was detected quite late (otherwise I would have chosen the backslash instead). In case your names contain slashes, these slashes have to be masked with a prceeding backslash and note 1535509 has to be applied. See for more information there.
../*
Code Example 5, .. (Parent relation)
Just for completeness reasons I mention here the parent relation which is defined for every access/dependent object (root objects don't have parents) and is represented by two dots following standard patterns. Technically there is another small difference to other relations since the parent relation returns the parent object, whereas normal relations return a collection. As for BPATH users this difference is hidden.
As for query result objects the parent is not defined also, above query would result in a parser error when executed on a UIFSearchResFlight object complaining that the target of the parent relation is either not existing or not ambigous. The second case will be treated later.
With the first examples we always returned a single element. But what if you wan to assemble the complete information? This is shown in the next example:
SearchResFlightRel/FlightBookRel/*$
Code Example 6, $ (add to table)
The dollar sign makes the difference. Up to now, the evaluation was stopped after the first entry found and the corresponding attribute or structure was returned. Now a table (of structures or of the attribute) is returned. This is also the case if only one entry is found.
The return structure is built up during procession, this can not be done if no data is found. In general applies to all BPath queries: If no data is found, NULL is returned.
The dollar may appear after any relation, but as it is used here we suggest to add it at the end. The differences between the approaches will be explained later.
That's it for today.
With the next lesson we cover the proper integration (including ABAP code) and we do further BPath examples highlighting structures and filtering.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
11 | |
10 | |
10 | |
9 | |
8 | |
7 | |
7 | |
7 | |
7 | |
6 |