BI4.1 Using End to End Trace with Scheduling Workflows

[former_member214314]

Hello everyone,

I'm new to blogging on SCN but I have been a Support Engineer for many years supporting several components in the BI Platform.  Currently I am part of the WebI team.

Some of the hardest issues to troubleshoot are those intermittent issues that seem to occur with no pattern.  We need to examine logs to see what happened when the failure occurred but how do you capture relevant logs if you can't predict when it will happen?

With the introduction of the End to End trace utility, we were able to get specific logs for a specific workflow.  This has been a huge timesaver when collecting logs for a workflow that was easily reproducible.  But what about those other issues - in particular schedules that fail intermittently?

I have recently learned that you can use End to End trace to gather traces for schedules also.

If you are "lucky" enough to have a schedule that always fails, you can use End to End trace while doing a "Schedule Now".  Most likely, however, you will have a daily schedule that fails once a week or so with no apparent pattern.  How do you trace just this schedule?

While it is not possible to trace only the failures, you can set the End to End trace on a specific Recurring schedule.

WARNING:  Please note that turning on this trace may cause unwanted performance hits and disk space usage.  Use with caution.

In this example, I have two Web Intelligence (WebI) reports:

Report AAAAA is scheduled to run every 5 minutes.

Report BBBBB is scheduled to run every 15 minutes.

At this point, if you are not familiar with End to End trace, you may want to visit SAP KBase 1861180 or the Remote Supportability blog that introduces the tool.  I prepared the system by editing the BO_Trace.ini setting append to false and the keep_num to 50.

I only want to trace BBBBB's schedule so I do the following steps:

Close all browsers

1. Start the SAP Client Plug-in (End to End trace utility)
2. Click on Launch to open Internet Explorer
3. Give the Business Transaction Name a meaningful name and set the TraceLevel to High

Now, before clicking on Start Transaction, do the following steps:

1. Log into CMC
2. Navigate to the Recurring Schedule
3. Pause the Recurring
4. Right Click on the Paused Recurring and Select
   Reschedule

5. Rename the Instance Title to something easily recognizable

6. Choose Create new schedule from existing schedule

7. Click Start Transaction in End to End Trace utility

8  Click on Schedule to finish creating the Recurring

You should immediately see the Sent bytes and Received Bytes increasing in the End to End Utility as the CMS should be actively logging the creation of the new recurring.

9. After a few minutes, click Stop Transaction in the trace utility.  (****Note: This does not turn off the tracing for the recurring****)

At this point, the BBBBB report has two recurring schedules:  The old one is paused and the new one is active:

If we check the properties in QueryBuilder,  there is a property SI_TRACELOG_CONTEXT that is different in the new recurring (after the End to End trace was activated)

I ran the following query in QueryBuilder to return the encrypted properties stored in the CMS database.

6968 is the object ID (SI_ID)  of the BBBBB report.  The recurrings are children of the parent report.

select SI_ID, SI_NAME, SI_TRACELOG_CONTEXT from CI_INFOOBJECTS where SI_PARENTID = 6968 and
SI_RECURRING = 1

In the BusinessTransaction.xml created from the End to End trace, the ID is 0050560100EB1EE4ABCA32A4509F8648

In the SI_TRACELOG_CONTEXT property of the BBBBB-EtoETrace, we see that this ID is embedded into the passport value.  This means anytime that this instance runs, it will turn on End to End trace.  So even though we stopped the trace in the utility, the End to End trace will start up again when the instance runs!

{tick=26;depth=2;root={name={component="CMC";method="WebApp";};id={host="BIPW08R2";pid=1180;tid=89;data_id=3356;step_id=1;};};caller={name={component="BIPSDK";method="InfoStore:schedule";};id={host="BIPW08R2";pid=1180;tid=89;data_id=3356;step_id=11;};};callee={name={component="cms_BIPW08R2.CentralManagementServer";method="commitEx4";};id={host="localhost";pid=4104;tid=8416;data_id=15958;step_id=1;};};vars=[{key="ActionID";value="ClU0nNrLbUO4j6T0giTH4Mgd1a";}];settings=[];passport="2A54482A03010D9F0D5341505F4532455F54415F506C7567496E2020202020

2020202020202020202000005341505F4532455F54415F5573657220202020202020202020

202020202020205341505F4532455F54415F52657175657374202020202020202020202020

20202020202020202020000553424F5020454E54455250524953455C42495057303852325F

363430302D636D303035303536303130304542314545344142434133343233354544464136

343820202000070050560100EB1EE4ABCA32A4509F86480050560100EB1EE4ABCA34356F29

464800000000000100E22A54482A01002701000200030002000104000858000200020400083

20002000302000B000000002A54482A";}

After I have paused the BBBBB-EToETrace recurring and resumed the original BBBBB recurring, the history page looks like this:

Meanwhile, schedule AAAAA has continued to run every 5 minutes.  We don't want all those traces in the logs!

So now we collect all the logs and check that only the BBBBB-EToETrace schedule traced….

To simplify, I’ll just look for START INCOMING CALL Incoming:processDPCommandsEx in the WebiLogs which gets generated when the webi report refreshes.

These “Information” traces occurred at 14:44, 14:51, and 15:06.

If you look at the BBBBB History page, you see that three instances were traced.

In this example, I don't have a failure so I do not need to analyze the logs. For more information on analyzing End to End trace files see Ted's blog on identifying root cause.

How to turn off the trace?    The safest way is to delete the recurring BBBBB-EToETrace.

When the SI_TRACELOG_CONTEXT property contains the TransactionID from the BusinessTransaction.xml created by the End to End trace, that schedule will continue to turn on End to End trace anytime it is run.  If that recurring schedule is migrated to a new system, it could also turn on an unwanted End to End trace there as well.  This could potentially cause a lot of mysterious and unwanted logging.

In my next blog, I'll investigate how End to End trace can be use with recurring Publication schedules.