Broadcast and subscription configuration changed with 7.4
Hi, we recently upgraded from 7.2 to 7.4 (20180313). Since doing so we've noticed various changes to broadcast settings:
- many sources that had broadcast enabled in 7.2 had it disabled in 7.4
- reports that had broadcast enabled in 7.2 had it disabled in 7.4
- some broadcasts had to be recreated after enabling at the source and report levels, while others did not
- some broadcasts turned into subscriptions and stuck while the source and report had broadcasts were disabled - in the below screenshot, this now subscription was previously a broadcast (I'd re-enabled broadcasts for the test below it).
I understand this is fairly broad-reaching and without much detail/other examples, but were there any likely changes in broadcast/subscription logic that could have caused these changes? And is there an easy way to determine which sources/reports have broadcasts disabled now but were previously enabled, and/or are linked to an active broadcast ID so we can reconnect broadcasts with reports and sources that are no longer active? We're re-enabled those that have been identified as missing but can't tell what else should be turned on again.
Thanks,
Brendan
The same question
Hi Brendan,
that reminds me of a bug from last year.
Could you please run the following query
and check the result set. The permitted values should be an integer from 0 to 7.
The reason for this is that the Broadcast permission is represented by 1, Subscribe = 2, and Data Profiling = 4. So any combination of those 3 permissions will give you that range of 0 to 7.
Please let me know what you find.
regards,
David
Hi Brendan,
that reminds me of a bug from last year.
Could you please run the following query
and check the result set. The permitted values should be an integer from 0 to 7.
The reason for this is that the Broadcast permission is represented by 1, Subscribe = 2, and Data Profiling = 4. So any combination of those 3 permissions will give you that range of 0 to 7.
Please let me know what you find.
regards,
David
Hi David,
We've run this against our two main instances and a lot of those values aren't 0-7, only the deleted sources appear to conform. Thoughts?
Thanks,
Brendan
Hi David,
We've run this against our two main instances and a lot of those values aren't 0-7, only the deleted sources appear to conform. Thoughts?
Thanks,
Brendan
Hi Brendan,
thanks for doing that, and yes, it definitely sounds like the defect I told you about (YFN-7897). Those 7 digit numbers you see in place of the values from 0 - 7 are data source IDs.
So, obviously to come up with a query to replace those data source IDs with a value between 0 and 7 is not hard, however, the hard bit is to know which exact value for each data source.
If we are lucky and it is not too much of a security issue for Acendre then you could just decide on a generic combination of permissions that is acceptable for all affected data sources (for example, a value of 3 would mean that Broadcast and Subscribe permissions are on but Data Profiling is off).
However, if that workaround is not acceptable to Acendre then I guess we will have to go about restoring the Yellowfin database from before the upgrade (hopefully one still exists) and then obtaining the correct SchedulesPermitted value from there.
If you would like some help with any of the above tasks then please let me know, I will be glad to help out.
regards,
David
Hi Brendan,
thanks for doing that, and yes, it definitely sounds like the defect I told you about (YFN-7897). Those 7 digit numbers you see in place of the values from 0 - 7 are data source IDs.
So, obviously to come up with a query to replace those data source IDs with a value between 0 and 7 is not hard, however, the hard bit is to know which exact value for each data source.
If we are lucky and it is not too much of a security issue for Acendre then you could just decide on a generic combination of permissions that is acceptable for all affected data sources (for example, a value of 3 would mean that Broadcast and Subscribe permissions are on but Data Profiling is off).
However, if that workaround is not acceptable to Acendre then I guess we will have to go about restoring the Yellowfin database from before the upgrade (hopefully one still exists) and then obtaining the correct SchedulesPermitted value from there.
If you would like some help with any of the above tasks then please let me know, I will be glad to help out.
regards,
David
Hi David, yes we'd wondered if those numbers were source IDs or the Source ID +/- a value to determine what permission was on or off. Certainly easier if it's meant to be a value from 0-7.
Are you able to list what each value from 0-7 means for permissions and we can look at updating them for each active source?
And will enabling these then re-enable reports that have had broadcasts disabled or will that be a separate issue to resolve?
Thanks,
Brendan
Hi David, yes we'd wondered if those numbers were source IDs or the Source ID +/- a value to determine what permission was on or off. Certainly easier if it's meant to be a value from 0-7.
Are you able to list what each value from 0-7 means for permissions and we can look at updating them for each active source?
And will enabling these then re-enable reports that have had broadcasts disabled or will that be a separate issue to resolve?
Thanks,
Brendan
Hi Brendan,
here are all of the combinations:
0 = Broadcast OFF, Subscribe OFF, Data Profiling OFF
1 = Broadcast ON, Subscribe OFF, Data Profiling OFF
2 = Broadcast OFF, Subscribe ON, Data Profiling OFF
3 = Broadcast ON, Subscribe ON, Data Profiling OFF
4 = Broadcast OFF, Subscribe OFF, Data Profiling ON
5 = Broadcast ON, Subscribe OFF, Data Profiling ON
6 = Broadcast OFF, Subscribe ON, Data Profiling ON
7 = Broadcast ON, Subscribe ON, Data Profiling ON
and I've just tested the workaround, after Yellowfin is restarted then it picks up the changes
If there are any further questions or issues please let me know.
regards,
David
Hi Brendan,
here are all of the combinations:
0 = Broadcast OFF, Subscribe OFF, Data Profiling OFF
1 = Broadcast ON, Subscribe OFF, Data Profiling OFF
2 = Broadcast OFF, Subscribe ON, Data Profiling OFF
3 = Broadcast ON, Subscribe ON, Data Profiling OFF
4 = Broadcast OFF, Subscribe OFF, Data Profiling ON
5 = Broadcast ON, Subscribe OFF, Data Profiling ON
6 = Broadcast OFF, Subscribe ON, Data Profiling ON
7 = Broadcast ON, Subscribe ON, Data Profiling ON
and I've just tested the workaround, after Yellowfin is restarted then it picks up the changes
If there are any further questions or issues please let me know.
regards,
David
Thanks for this - we'll apply and test the outcome. To confirm, will this then re-enable the reports that were previously enabled for broadcasts but disabled in the upgrade as well? If not, how do we identify reports that did have a broadcast but were disabled?
Brendan
Thanks for this - we'll apply and test the outcome. To confirm, will this then re-enable the reports that were previously enabled for broadcasts but disabled in the upgrade as well? If not, how do we identify reports that did have a broadcast but were disabled?
Brendan
Hi Brendan,
yes it will re-enable the reports that previously had broadcasts enabled but became disabled after the upgrade.
Here are the steps I did to test that:
1) Picked a data source with SchedulesPermitted = 7 (i.e. Broadcasts, Subscribe, and Data Profiling were allowed enabled)
2) Created a report based on that data source, and confirmed that it did have the Broadcast option enabled, and then created a Broadcast.
3) Changed the data source's SchedulesPermitted value from 7 to 6 (i.e. only Subscribe and Data Profiling enabled)
4) Restarted Yellowfin
5) Confirmed that the report had lost the Broadcast option (by the way, it still had the Broadcast created previously)
6) Changed the data source's SchedulesPermitted value from 6 back to 7
7) Restarted Yellowfin
8) Confirmed that the report had regained the Broadcast option, and the previously created Broadcast still existed.
Please let me know how you get on with this.
regards,
David
Hi Brendan,
yes it will re-enable the reports that previously had broadcasts enabled but became disabled after the upgrade.
Here are the steps I did to test that:
1) Picked a data source with SchedulesPermitted = 7 (i.e. Broadcasts, Subscribe, and Data Profiling were allowed enabled)
2) Created a report based on that data source, and confirmed that it did have the Broadcast option enabled, and then created a Broadcast.
3) Changed the data source's SchedulesPermitted value from 7 to 6 (i.e. only Subscribe and Data Profiling enabled)
4) Restarted Yellowfin
5) Confirmed that the report had lost the Broadcast option (by the way, it still had the Broadcast created previously)
6) Changed the data source's SchedulesPermitted value from 6 back to 7
7) Restarted Yellowfin
8) Confirmed that the report had regained the Broadcast option, and the previously created Broadcast still existed.
Please let me know how you get on with this.
regards,
David
Thanks Dave, we've applied this to our instances and, as far as we know, it has re-enabled the reports for broadcasting as well.
It's hard to tell, however, as we are experiencing some interesting (confusing) behaviour with broadcasts. Broadcasts that haven't run since the upgrade (as they're monthly etc) aren't appearing in schedule management, while old broadcasts that are well past the end date are there (and some are running again). Other broadcasts that appear in schedule management don't appear against the report. And these don't always match up with the broadcast records in the database, so we're trying to match things up to work out what broadcasts should be firing when. Is this likely to be a bug, or expected, or otherwise?
Regards,
Brendan
Thanks Dave, we've applied this to our instances and, as far as we know, it has re-enabled the reports for broadcasting as well.
It's hard to tell, however, as we are experiencing some interesting (confusing) behaviour with broadcasts. Broadcasts that haven't run since the upgrade (as they're monthly etc) aren't appearing in schedule management, while old broadcasts that are well past the end date are there (and some are running again). Other broadcasts that appear in schedule management don't appear against the report. And these don't always match up with the broadcast records in the database, so we're trying to match things up to work out what broadcasts should be firing when. Is this likely to be a bug, or expected, or otherwise?
Regards,
Brendan
Hi Brendan,
not sure, I'm wondering whether the reason might be that if all data sources have now all been set to the same value (say 3), but some of them may previously been 0, 2, 4 or 6 then that would perhaps trigger broadcasts that previously weren't being sent.
I will test this theory out over here and let you know...
regards,
Davdi
Hi Brendan,
not sure, I'm wondering whether the reason might be that if all data sources have now all been set to the same value (say 3), but some of them may previously been 0, 2, 4 or 6 then that would perhaps trigger broadcasts that previously weren't being sent.
I will test this theory out over here and let you know...
regards,
Davdi
Hi Brendan,
Here's an interesting finding - I created a broadcast with a frequency of 1 MIN and confirmed that it is sending correctly, then went to the data source and turned off the broadcast permission, however the broadcast kept being sent. But if in the same report if I go to create a 2nd broadcast then it is not possible.
So this means that reconfiguring the broadcast permission on the data source does not affect broadcasts that were created prior to the permission change, it only applies to new broadcasts.
As to how this ties in with our current investigation into the 7.4 upgrade issue, I guess it helps us to rule out this current ticket's issue as being the cause of the performance and broadcast issues in the 7.4 upgrade Yellowfin.
Have you guys still got a backup of the 7.2 YF DB? If so then I think it could be worth me getting a copy of it and doing an upgrade over here, what do you think?
regards,
David
Hi Brendan,
Here's an interesting finding - I created a broadcast with a frequency of 1 MIN and confirmed that it is sending correctly, then went to the data source and turned off the broadcast permission, however the broadcast kept being sent. But if in the same report if I go to create a 2nd broadcast then it is not possible.
So this means that reconfiguring the broadcast permission on the data source does not affect broadcasts that were created prior to the permission change, it only applies to new broadcasts.
As to how this ties in with our current investigation into the 7.4 upgrade issue, I guess it helps us to rule out this current ticket's issue as being the cause of the performance and broadcast issues in the 7.4 upgrade Yellowfin.
Have you guys still got a backup of the 7.2 YF DB? If so then I think it could be worth me getting a copy of it and doing an upgrade over here, what do you think?
regards,
David
Hi Dave, we do have a backup of the 7.2 DB - let me know how we can transfer you a copy for you to test with.
Thanks,
Brendan
Hi Dave, we do have a backup of the 7.2 DB - let me know how we can transfer you a copy for you to test with.
Thanks,
Brendan
Hi Brendon,
we've got a new FTP site:
http://yellowfin.brickftp.com/
and you don't need an account to use it, you just upload your file(s).
regards,
David
Hi Brendon,
we've got a new FTP site:
http://yellowfin.brickftp.com/
and you don't need an account to use it, you just upload your file(s).
regards,
David
Hi Brendon,
seeing as I haven't had any response from you I will close this ticket for now.
However, if you ever would like to re-open it then just add a new post to it and that will automatically put it back in the Support Team work list with the status of "In Progress"
regards,
David
Hi Brendon,
seeing as I haven't had any response from you I will close this ticket for now.
However, if you ever would like to re-open it then just add a new post to it and that will automatically put it back in the Support Team work list with the status of "In Progress"
regards,
David
Replies have been locked on this page!