Broadcasts in schedule but not on reports

Hi Brendan,

I don't know what caused this and haven't heard of this issue previously. If a broadcast is deleted via the report menu (in which case it is end-dated in the ReportBroadcast table) then it is also removed from the Schedule Manager (in this case it is completely removed from the TaskSchedule table, not just end-dated). So it is hard to imagine how the situation came about that a previously removed row in the TaskSchedule table has reappeared.

Most likely it is either a bug or perhaps there have been some back-end modifications to the Yellowfin database.

Could you please tell me which build of 7.2 this occurred in so I can test for the issue over here.

Regarding the possibility of auditing via the logs or the tables, I've checked the Event table and found that there is an EventCode called 'RPTBROADCASTCREATE' that is used when a new ReportBroadcast (and hence a new TaskSchedule) is created. So I guess you could search the Event table for rows in the last few weeks that have EventCode = 'RPTBROADCASTCREATE', and when you have located them you can find the reportID in the column called "EventData" which will confirm whether it is one of the broadcasts that have reappeared after being deleted.

Unfortunately there is nothing entered in the log files (when the logging level is INFO) when a ReportBroadcast is created, so once again, this does not help us to audit the issue.

Is Yellowfin allowing you to deleted the orphaned TaskSchedule records via the UI? If not please let me know then we can work out a way to delete them via the back-end.

regards,

David

Hi David,

Thanks for looking into this. We can delete from the TaskSchedule records from the Schedule Manager. Our build is 20170404.

Regards,

Brendan

Hi Brendon,

OK. I've been playing around with that particular build of 7.2, for example, creating a report in the Default org then opening the report in a Client org and creating a broadcast there. Then removing the broadcast via the Schedule Manager. Then doing various permutations of these steps such as creating the report in the Client org instead of Default, creating the broadcast in the Default org, creating the broadcast in both orgs, deleting the report and not the broadcasts etc. and eventually even though I wasn't able to replicate exactly the issue you have experienced, I did in fact come across the following issue: I deleted a broadcast via the Schedule Manager, however Yellowfin still shows the report as having a broadcast in the Browse screen. I have attached a short video that demonstrates this.

Even though this is not the same issue as the one you have experienced, because of the nature of it I think that it must be related.

Then I tried to replicate this same issue in the latest 7.2 (20171023) but was not able to.

So because of these findings I'm wondering if you'd be able to test an upgrade to the latest build of 7.2 to see whether the issue you are experiencing will also be resolved? I know that this is based upon only an assumption that the 2 issues are related, but it's the best I've got to go on at the moment. What do you think, would you be able to test such an upgrade?

regards,

David

Hey David, thanks for having a good look into this and testing from a number of angles! We're currently looking at an upgrade to 7.4 in the next few months so going through a build upgrade of 7.2 may or may not fit into that schedule, but I'll raise it with our engineers.

Similarly, another recent broadcast issue may be related as well - opening up the broadcast details in a report can take a number of minutes to load. This is happening across a number of client orgs (and reports and broadcasts). Do you think this may also be a build issue that may be resolved with an upgrade, or something else?

Thanks,

Brendan

Hi Brendan,

good news, that other broadcast issue was definitely a known issue and there was an enhancement (YFN-7534) last October to improve the performance.

The problem was that there used to be a hard-coded value of 90 days for Yellowfin to lookup the Event table in order to find out how many times the broadcast had been run:

and as you can imagine this could take more time on how many records are in the Event table, and the performance could get especially worse if Yellowfin had to hit the Event Archive table as well.

The improvement to the code is that now the lookup period is configurable by running the following query against the Yellowfin database:

INSERT INTO Configuration (IpOrg, ConfigTypeCode, ConfigCode, ConfigData) values (1, 'SYSTEM', 'REPORT_BROADCAST_EVENT_TABLE_LIMIT', 2)

where the ConfigData value represents the number of days. And if you set that to 0 then it turns off the search altogether.

So in summary, an upgrade to the latest build/version will definitely fix that performance issue.

regards,

David

Hi David,

We're currently testing 7.4 (build 20180313) and are still experiencing this issue e.g. long load times on the broadcast configuration. Is there a possibility this build doesn't include this fix, or could something else be causing this?

Or do we have to upgrade 7.2 20170404 to 7.2 20171023 before then upgrading again to 7.4 20180313?

Thanks,

Brendan

Hi Brendan,

I've just tested the 20180313 build of 7.4 for enhancement YFN-7534 and it is working fine for me, so therefore I can say that this build definitely includes the fix. Also, the upgrade path shouldn't matter.

I have attached a short video to demonstrate it working correctly. In it you will see that firstly, Yellowfin doesn't have the new Configuration parameter "Report_Broadcast_Event_Table_Limit" and you can see that by default the Report Broadcast searches back 90 days through the Event table. Then I insert that new Configuration parameter with a value of 0 to turn off the search completely, restart Yellowfin and then it didn't search back 90 days anymore, in fact it didn't search back any days.

I'm trying to think of reasons why it isn't working for you and I've come up with 2 things that are very quick to check, maybe there was a typo when you ran the backend query, in which case it would be worth checking over by running the following query:

SELECT * 
FROM Configuration 
WHERE ConfigCode = 'Report_Broadcast_Event_Table_Limit'

Also, maybe Yellowfin wasn't restarted, with that in mind it would be good if you could confirm it was restarted after the backend modification.

So if you could let me know about those two things, that's be great, and in the meanwhile I'll try and think of how to proceed from here if either of them were not the cause.

regards,

David

Hi Brendan,

just wondering whether you managed to get the Report_Broadcast_Event_Table_Limit working?

regards,

David

Hi Dave, thanks for following up. I don't think this addressed it directly as it didn't seem o make any difference, however once we deleted a whole bunch of old records in the broadcast event table it significantly improved the performance of 7.4. So I'm unsure if it was just that or the combination of less records and the above table limit.

We'll have to see if we can replicate this change when upgrading production to 7.4

Thanks,

Brendan

Hi Brendan,

that's a pity it didn't seem to help. It would be interesting to learn how many days you set the new Report_Broadcast_Event_Table_Limit to be. If it were something like 30 days then I can imagine that if the Event table was huge then it would be possible that even though 30 days is much less than the default 90, it could still mean a big search of thousands of rows. However, if you actually turned off the feature by setting the Report_Broadcast_Event_Table_Limit value to be 0 days then that sounds very strange.

regards,

David

Hi Brendan,

I'm just checking in on this issue and wondering how you got on with it (and whether you did try to set the Report_Broadcast_Event_Table_Limit value to be 0 days)?

regards,

David

Hi Dave,

We didn't see a huge improvement in broadcast loading time when we made this change to be honest - we had much more effectiveness by deleting old events from the broadcast event table. This may not have been a recommended approach (!) but this was tested in QA and seemed most effective.

Thanks,

Brendan

Hi Brendan,

yes I totally understand!

I guess I was more trying to find out whether the Report_Broadcast_Event_Table_Limit functionality was actually working or not. In other words, if you set the value to be 0, then the calendar won't be displayed. Do you remember if that is what happened?

regards,

David

Hi Brendan,

I'm closing this for the moment because it seems to be finished, however, if you ever want to pursue the matter again just add a new post to this ticket and that will automatically re-open it and add it to the support work list.

regards,

David