Insight into calculated fields created by AET

[JerryWang]

• how to create calculated field


• What artifacts are generated for the calculated field in the backend

• 1. What is the new field added to Genil model?


• 2. new FDT rule and related artifacts


• 3. the new generated mapping class


• How to trace the calculation logic done in the runtime
  
  
  
  • 1. maintain the user parameter AXT_RULE_TRACE_MODE as X in your user profile.
  
  
  • 2. goto tcode SAAB, activate checkgroup AXT_GENERAL.
  
  
  
  


• How to debug the calculation logic in the runtime


• why the calculated field is empty when UI is in display mode

This document tries to explain more technical background regarding calculated fields created by AET. It talks about technical implementation of calculated fields and how to trace & debug if you find it does not work as expected.

how to create calculated field

This document will not cover how to create new field via AET step by step, as plenty of documents could be found in SCN.

I just launch AET and create a new field on Product header. Mark "Calculated" checkbox in field creation dialog:

in this document, I just use the simple logic as example: the content of this calculated field comes from the email address maintained in my user profile, and it could be automatically converted to lower case, as I select the TOLOWER String function in formula definition below:

Below is the result: the email address maintained in my user profile will be filled automatically to this extension field in UI.

What artifacts are generated for the calculated field in the backend

Lots of artifacts are also generated under the hood in the ABAP backend. All of them works together with AET framework to ensure the calculation logic is executed smoothly in the runtime.

1. What is the new field added to Genil model?

We have defined the calculation logic on the extension field. Click F2 and identify its technical attribute name: ZZFLD0000YP.

Then we can look into Genil component PROD in tcode GENIL_MODEL_BROWSER, and find the extension field is modelled as one field of dependent object ProdSetCRM_EXT_MAT, which could be available via Aggregration ProductSetCRM_EXT_MAT from root node. So we are sure in the runtime, the field ZZFLD0000YP will be filled by AET framework with my email address.

2. new FDT rule and related artifacts

We can also view the new field via tcode AXTSHOW, input field name ZZFLD0000YP and execute report.

From result we could know that technically speaking, one FDT rule with two parameter mappings are generated for the calculated field we create via AET.

The rule type FDT_FORMULA in the above picture gives us a hint that the rule could be viewed by BRF( Business Rule Framework) workbench. The workbench could be launched via the following Webdynpro application:

Workbench->Open Object:

Search application via RULE ID 0050569457471EE3A6D6AF56EF33F505 found in report execution result:

click Formula node in the left navigation tree, click "Start Simulation" button:

Maintain simulation test data and click Execute:

Simulation done successfully, we get expected result.

3. the new generated mapping class

Query the table FDT_CC_0000 with rule ID got from tcode AXTSHOW, you can find there is also a new class /FDT/00O2TJ6G8AL233VMEEX143HVF generated.

we will discuss the usage of this mapping class in debugger chapter of this document.

How to trace the calculation logic done in the runtime

Before the introduction of debugging calculation logic in the runtime, we first look into how to trace the calculation logic. Sometimes by tracing it is possible to find the issue root cause to avoid time wasted in debugging.

1. maintain the user parameter AXT_RULE_TRACE_MODE as X in your user profile.

2. goto tcode SAAB, activate checkgroup AXT_GENERAL.

activate the kogpoints:

after activation, re-launch your application in UI. You should find many log entries written in SAAB.

Double click on the entries and you could observe the expected email address is successfully written into <LV_FDT_RESULT>.

How to debug the calculation logic in the runtime

If trace function still could not help you find the root cause why the extension field does not work as you expected, you have to debug it yourself.

Please always ensure the calculation logic works fine in simulation mode, before you start debugging.

The question is where we could set breakpoint for starting? The generated mapping class /FDT/00O2TJ6G8AL233VMEEX143HVF is a good place, just set a breakpoint in its method IF_FDT_GEN~PROCESS. However it is better if we could know how our mapping class is called by AET framework.

Everytime the GET_PROPERTY of CL_CRM_BOL_ENTITY is called, inside it the method MAKE_VALID_STATE is called to evaluate whether a reread or property calculation is necessary.

as our calculated field is filled by mail address of "USER", the data source provider class for it is maintained in the table below:

the class is responsible for email address retrieve via user BAPI:

and our mapping class is called here:

why the calculated field is empty when UI is in display mode

as is explained earlier, the calculation logic is triggered in line 93, however when the product instance is searched out from database and shown in product UI in display mode, the property_calculator_registered of the bol entity is initial, so the calculation logic has no chance to execute.

only when a BOL entity is locked by edit button, the lock event will trigger focus changed event and lead to the creation of new dependent object ProductSetCRM_EXT_MAT's entity,

the flag =>V is filled by BOL framework here.

In display mode all the above logic has no chance to executed thus the calculated field is displayed as empty in UI.

Hope this document is helpful for you when dealing with AET calculated field.