Skip to Content

Please find below blog content migrated on behalf of Bernd to the TM SCN community:

How to use the magic Data Crawler for Conditions

This document describes in brief how to use the data crawler to define input for conditions. The example describes how to read TRQ root data for a condition which is called for a Freight Unit, e.g. the default MTR determination. The document URL will be available shortly here. Check back shortly!

How does TM conditions technically link to BRFplus

The Conditions in Transportation Management are just a small wrapper around BRFplus, they define and provide the context specific input (with the data access definitions) and the output format. The actual magic happens in BRFplus. Every condition creates a BRFplus Application and function with the name of the condition(thats why special rules apply to the cnoditions naming) and in case of a decision table based condition a decision table(which is an expression in BRFplus terms).

Now, how do the two objects actually technically linked? Lets take the following Condition as an example:

Technically there are only few fields that do the link.

In the Condition (the BO name is /SCMTMS/CONDITION_DEFINITION) header the GUID of the BRFplus application, Function and Expression (in our case the decision table) is store. At runtime the BRFplus function is called, this is e.g. also the level where you can perform the complete simulation in BRFplus.
The picture shows a screenshot from the condition (in BO testtool) and the BRFplus function (from BRFplus workbench), the function FDT_FUNC_GUID is
identical to the Function ID.

Now we already have the link on header level. The second part is the link between the data access definitions and the Function Signature(which is the
context data that can be used in the BRFplus function) in BRFplus. This is defined in the node DO_DATA, here is another screenshot from the BO-Testtool and the BRFplus view on it:

28-03-2012 09-11-30.png

The example shows the colums of the decision table which are entries in the DO_DATA node in the conditions and the function context in BRFplus, the DOBJ_ID in the condition is the GUID of the context Data object in BRFplus(on the right hand side there BRFplus function context and one of the data objects are shown).

   

PS: All this of course only applies to BRFplus beased conditions, not to conditions with direct BO access.

PPS: You might wonder why the GUIDs are called FDT…when we started to integrate BRFplus it was called Formula and Derivation Tool and then rebrandet to BRFplus… see what the wikipedia says about BRFplus history: http://de.wikipedia.org/wiki/BRFplus

            

How to use conditions in your custom developments

In customer projects sooner or later you come into a situation where you want to enhance and need a way to determine data. In the old world you have created a Z-table, in TM you have the possibility to create your own condition types and reuse the conditions in your own coding.

And here is what needs to be done:

1. Condition Type: For this scenario we assume you are reusing an existing condition type like /SCMTMS/TOR_GENERIC which returns a
generic result. If you need a specific result of the condition and this should be reflected in search helps etc. you may even create yout own condition type,
but this is another story and will be handled in another posting.

  

2. Do the actual condition call: To call the condition you basically have 3 steps:

2a. Collect the documents (e.g. Freight Order Keys) and the condition ID you want to use. In the example we loop over the TOR root node and extract the key of all TORs with the type 1234. The name of the condition is ‘DEL_PROP_RELEVANCE.

loop lt_tor_root into ls_tor_root where TOT_TYPE = ‘1234’.

insert ls_tor_root key into table lt_tor_key.

endloop.
* The condition name is hard coded here, it could also come from
a method attribute
lv_cond_id = ‘DEL_PROP_RELEVANCE’.

2b. Now do the actual call to th condition method, this is as simple as this:

TRY.
CALL METHOD
/scmtms/cl_cond_ol=>proc_conditions(
EXPORTING
it_boinst_key =
lt_tor_key

iv_cond_id = lv_cond_id
IMPORTING
et_bokey_cond_result =
lt_bokey_cond_result
CHANGING
co_message = lo_tor_create_request->mo_message ).
CATCH /scmtms/cx_cond_processing.

 

ENDTRY.

2c. Finally you have to extract the results and process them in you coding.
To do so you read the hit in the result table for you Freight Order and do what you need to do with it:

* LOOP AT lt_tor_key INTO ls_tor_key.

READ TABLE lt_bokey_cond_result with key BO_KEY = ls_tor_key-key.

IF ls_bokey_cond_result-result_single = abap_true.

* Here is where you react to the condition result, in the example the condition returns a TRUE and this may trigger certain follo up steps

ENDIF.
ENDIF.
ENDLOOP.

PS: In your coding you should always consider the possibility would not find a result and have a default reaction.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

  1. Renato Chin

    Hello Natalie,

    I have understood your code, but my doubt is where I put this code? In which point of the program? Is it an condition enhancement, user-exit, Badi…

    I have a similar scenario. I have to make a loop into a Freight order for all Freight Units to test some fields and give me a result.

    Thanks for help!

    Renato

    (0) 

Leave a Reply