These Enhancements are added as part of v184.108.40.206 (9.1 FP 34)
What is transaction tracing:
Transaction tracing is feature which allows user to set trace level for specific invocation of API or service. This feature is useful when you want to collect logs for diagnostic purpose when API/service which is causing the issue issue is known, but logs cannot be enabled as there are multiple invocation of this API/service and system will be flooded with logs when normal trace is enabled.
Once transaction tracing is enabled TransactionTracingLevel attribute needs to be passed in input XML of the API/service call which needs to be traced. Only API or service call with TransactionTracingLevel attribute present in input XML with valid value will be traced.
Valid values of TransactionTracingLevel attribute are same as out of the box trace levels i.e. VERBOSE, DEBUG, SQLDEBUG and TIMER.
Example: In production issue is reported for changeOrder API. Issue occurs only for few type of modifications. Customer knows the input XML of changeOrder call. However changeOrder API cannot be put on trace as there will be thousands of call per hour to changeOrder API.
In this scenario transaction tracing needs to enabled and changeOrder API needs to called with TransactionTracingLevel="VERBOSE"
<Order TransactionTracingLevel="VERBOSE" ..... />
ps: Transaction tracing needs to enabled for product to honor TransactionTracingLevel attribute passed in input xml for API/service. If traction tracing is not enabled and TransactionTracingLevel attribute is passed in input xml of API/service then no logs will be generated.
How to enable transaction tracing:
From System Management Console
By using modifyTraces API
Call modifyTraces API from API with following input XML
<Trace Action="ADD" Level="" Name="TransactionTracing" ServerId="" ServerName="" Type="TransactionTracing"/>
ps: TraceLevel will be blank while enabling transaction tracing. TraceLevel will be decided by TransactionTracingLevel attribute present in the input xml of API/service call.
What is user tracing:
User tracing is feature which allows us to trace APIs and services invoked by the particular user while performing his/her activities.
This feature is useful
When issue occurs from UI and we are not sure what all APIs or services are called in backend. Logs cannot be enabled as not all the API/services invoked in the activity performed by the user are known.
When issue occurs for particular users only.
In both the above scenario enabling user tracing will help us gather logs for diagnosis.
ps: User tracing is specific to user. Logs will be generated for all the APIs and Services invoked by the user for which user tracing is enabled. Logs will not be generated for other user performing same activity.
How to enable user transaction tracing:
From System Management Console
By using modifyTraces API
Call modifyTraces API from API with following input XML to enable user tracing for TestUser
<Trace Action="ADD" Level="VERBOSE" Name="admin" ServerId="" ServerName="" Type="UserTracing"/>
Configuration Data Dump:
What is Configuration Data Dump:
Configuration Data Dump is feature which will allow us to collect configuration data and master data accessed by the API. When configuration data dump is enabled, data is collected when API encounters an error or API is executed in VERBOSE mode.
For example scheduleOrder API is scheduling order on unexpected date. scheduleOrder VERBOSE logs in not throwing much light on configuration which is causing this issue. Then configuration data dump can be used to collect configuration and master data used by scheduleOrder logs during its execution.
This feature can be enabled to collect data only when API encounters error OR only when API is executed in VERBOSE mode OR both on API error and when API is executed in VERBOSE mode.
Configuration data is published in VERBOSE logs just after the API call end. Search for dumpConfigurationData - Begin after API call.
When API encounters an error then configuration data is published in %INSTALL_DIR%/logs/ffdc folder.
This feature uses ConfigurationDataDump.xml file present in %INSTALL_DIR%/resources folder to decide on table type for which data need to be collected, API and tables which needs to ignored. Adding tables for which data should not be collected. Also defining number of maximum records to be published for particular table type or table.
It is not recommended to modify ConfigurationDataDump.xml file.
Sample config data collected on error
Sample config data collected on VERBOSE
How enable Configuration Data Dump:
In customer overrides, yfs.api.configuration.dump.mode property needs to be set to one of the valid values.
NONE - disabled
ON_ERROR - On the occurrence of an exception during the API execution, irrespective of the tracing level configured in System Management Console for the API, Configuration Data and Master Data are dumped in a separate log file
ON_VERBOSE - This is the default value. If an API is executed with VERBOSE level of tracing, then on successful completion of the API, Configuration Data and Master Data are dumped into the standard log file.
ON_ERROR_AND_VERBOSE - Configuration Data and Master Data are dumped on occurrence of exception and also, when the API is run with VERBOSE level of tracing
Standalone API tester:
A standalone API tester has been introduced. Stand alone API tester can be invoked from %INSTALL_DIR%/bin folder by executing apiTester.cmd (windows) or apiTester.sh (non-window OS).
How to use:
Run apiTester.sh (or apiTester.cmd) from %INSTALL_DIR%/bin folder.
Enter username/password and click on login.
On successful login select API (which needs to run) from API Name drop down
Pass input XML and required output template.
Click on RunAPI
ps: Input XML and output template can be passed from the file also by selecting appropriate option from File menu. Output XML can also be saved to file.
Salient features mentioned in release notes:
Quick and easy to launch. No need to start Application Server.
Can enable tracing at run time. Set the trace level to VERBOSE in the root element of the API input XML.
Log file is saved in <INSTALL>/log.
Can save the output of the API in file.
Can use external file as input or template.
Can invoke services by wrapping it in multiApi .
Input XML is automatically picked up on selection of API, if input XMLs are present in the APIInputDir. The input file name should be same as API name, for example, for createOrder API input file must be createOrder.xml and placed in APIInputDir.
Default path of the APIInputDir is <INSTALL_DIR>/apiinputs. A user can change the path by setting system property APIInputDir inapiTester.cmd/sh.