Quick and Dirty (QAD) – 01 BCV and TM Conditions (using BRFplus)
First of all, we have lots of acronyms in the title, so here is the full explanation: Quick and Dirty: Business Context Viewer and Transportation Management Conditions (using Business Rule Framework plus)
So, last week I was playing around in a TM 8.1 system and wondering about the functionality of BCV (Business Context Viewer). I had seen some fancy screenshots with context based information for a TM document, so I decided to give it a shot, using a TM condition.
The use case would be very simple: Based on given field(s) in the Forwarding Order (e.g., the Incoterm code), display a corresponding picture/chart in the BCV panel to the right (in the given example, a chart describing the responsibilities for buyer/seller)
Here is the result:
The picture to the right is retrieved based on the entry in the Incoterm field. If I change the entry to DDP, save the FWO, and refresh the view, the DDP diagram is displayed:
here is the refresh:
and the update:
What is happening here in the background? Let’s take a look at the involved components. We have:
- A TM condition that uses a BRFplus decision table to map Incoterms to images
- The BCV objects that are linked to the FWO BO, and which:
- call the TM condition
- and display the result in form of an image on the side panel
Let’s detail this a step further:regarding 1: The decision table for the TM condition looks like this:
You can see the simple mapping between the Incoterm and the image (which is just a URL that points to the image). So this condition just returns the URL defined for a specific Incoterm code.To create this condition I had to define a condition type:
and a Data Access Definition (DAD) to extract the Incoterm:
Then I linked the DAD to our condition type, and created the condition, which you saw above.And how can we use this condition? This is where the BCV objects come into play. I’m by no means a BCV expert. But you might get the idea anyway (and BCV experts are welcome to chime in and give a hand).(of course, BCV has to be configured in the system, so there are some steps that have to be done first. You can refer to the SAP library, which explains it quite well: http://help.sap.com/saphelp_tm80/helpdata/en/01/01a02e106d4d3bb3f249c429e60cd0/frameset.htm)so, regarding BCV: We have the following main BCV objects (all of these can be defined in the Configuration Center in the NWBC (roles SAP_BCV_ADMIN, SAP_BCV_USER)):
- Search connector (BAPI)
- BCV Query
- Query View
The Search connector is the object that allows us to call our condition. There are several types of connectors available (Business Intelligence, Enterprise Search, etc..). We use a BAPI Search connector to implement the call to our TM condition.
Here is what I did (this is the coding part): I took existing coding for a BAPI search connector and copied it. Then I replaced the relevant code. Here is the coding for the condition call:
This call triggers our condition, which extracts the Incoterm. Then it returns the URL of the corresponding image. In the coding you can see the ID of the condition we created before. And the variable lt_trq_key contains the key of our Forwarding Order, so that the condition knows where to extract the Incoterm. The connector looks like this in configuration:
The red box shows where the coding is defined. The tabs show which is the input field (the root key of the Forwarding Order) and the output field of the connector (the image URL).
But, how is this key passed to the Search connector in the first place? And what happens to the image URL after the condition worked its magic?
This is where the BCV Query comes into play:
The BCV query is linked to the search connector (1.). Furthermore, it is linked to the BO via the context key (2.). So whenever a BO is telling BCV “hey, my context key is ABC”, BCV finds the queries that have “subscribed” to this context key. Then, some variables are passed by using “meanings”, so in our case the Root key of the Forwarding Order is passed and mapped to the input field of the Search Connector, TRQ_KEY (3.). Lastly the search connector can be executed. All of this is what caused most of my troubles, and in the end I had to sacrifice elegance for the sake of just making it work (again, hence the title).
Another important thing for the BCV query is to change the output field to “URL Image”. Otherwise, the URL is not interpreted as an image, and the side panel just displays a URL:
After the BCV Query, the rest is easy. We have to create a Query View:
The query view is how we make the result from our BCV Query visible to the user. There are many options to present the information (restricted by authorization, shown via Xcelsius, tables with colors (ALV grids), Forms, etc..). We will just show a picture. For this we have to create a chart view of the type form. This is how it looks like in configuration:
Here we map the query and the query result field (we just have one). As mentioned, BCV does the rest and displays the URL as an image.
Lastly, we create an Overview to include our query view. An Overview gives the possibility to display many query views in different layouts (in our case, an overview is not really necessary, as we can access the query view directly in the BCV side panel in TM). Here it is in configuration:
and the corresponding layout, with the catalog of available query views and layout controls:
After that, we just need to open a forwarding order and maintain a value for the Incoterm. This will retrieve the corresponding image, as shown before.
This example is very static in the result (just an image, no charts or calculations), but very flexible in the rules to determine the image. It was done almost completely with configuration, with very little coding involved. And best of all, it can now be used to display any kind of image, based on every type of field(s) from the TRQ BO (or even associated BOs), using the power of TM conditions.
Hopefully you found this post to be useful, and I would be glad if you have comments or questions. Take care!