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:
- XML data is always organized as a hierarchical, finite tree. This is not the case for Business Data.
Even though business data may appear to be hierarchical organized (on storing a Business Object one typically saves an hierarchically organized sub-tree), in general it is not. Relations can occur from any node to any other node and infinite pathes can be found without problem. So we have to conclude that Business data is neither hierarchical nor finite. Consequently it is not possible to apply some of the features of XPATH (as the searches on all nodes of the subtree). - The start object for the Bpath has to be provided always (equally the XML document has to be provided for XPath). Since we always operate from the starting object the differentiation between relative and absolute pathes makes hardly sense.
- Since hierarchy and finiteness are not guaranteed even for a (business) root object, there is no way to "scan" the complete tree. As a consequence the "//" operation as known in XPath (I cite from w3schools: "Selects nodes in the document from the current node that match the selection no matter where they are") has no counterpart in Bpath.
- The data returned by the XPath is also an XML entity and can be structured very inhomogeneous. The return of BPATH is either a flat collection or an data structure. In both cases there are limitations in respect to the inhomogeneity we can handle. For example it is practically not possible to deal with requests as //book | //cd
- Some concepts as "Parent" and the prefixing of attributes with @ and the notation in respect to relations are quite similar in both concepts. Note that in XML the names refer to the objects, whereas the names used in BPATH refer to the relations between the 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:
- BPath is available with WEBCUIF 7.0 EhP1, shipped with CRM 7.0 EhP1 (and to my knowledge with the SAP Business Suite 7 Innovation 2010)
- Base of a query is either a Business Object or a "Business Collection with Uniform Entity Type" (CL_CRM_BOL_ENTITY_COL_UT)
- for all examples we use the standard "FLIGHT" model, more exactly we use an UIFSearchResFlight query result object or collection as base.
- If a query execution runs into a problem, a shortdump will be raised. This might be either the dump from the underlying layers or a CX_WCF_BPATH_PARSING_ERROR.
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.
