Not all Subscriptions are listed with mstrio.distribution_services.list_subscriptions()

[martinuphoff]

I am having trouble listing all subscriptions of a project. There are a lot of them missing. I am personally interested in the CacheUpdateSubscriptions, but the numbers don't add up anyways, even if I don't filter on that. Currently fetching it like this:

with Connection(
    base_url=base_url,
    username=mstr_username,
    password=mstr_password,
    project_name=project_name,
) as con:    
    subscriptions = [
        s
        for s in list_subscriptions(connection=con, project_name=project_name)
        if isinstance(s, CacheUpdateSubscription)
    ]
    print(f"Number of subscriptions: {len(subscriptions)}")
    for subscription in subscriptions:
        print(subscription.name)

It dind't change when I used different users (admin, owner of the subscription, me (admin user)). In Workstation and Developer they get listet correctly, also filtering on Type and Project name works fine there. Has anyone encountered such a behaviour? Best regards, Martin

[hustontrevor]

It shouldn't be possible that WorkStation returns a larger subscription list than mstrio since they both use Library to communicate with the iServer. Return all subscriptions and see if the ones you are missing are coming back as a different instance type.

I have found that some subscriptions simply didn't return in WorkStation. For example, WorkStation won't show "Personal View" subscriptions even though they do return in Developer and mstrio list_subscriptions().

Though cube cache subscriptions return for me in Update 12, I was unable to create or edit the cube cache subscription in mstrio. I had to output a txt file of Command Manager scripts to run.

if "content can only be report, document or dossier type for 'CACHE' mode.;" in error_result: 
                                    if 'recipients' in ssub:
                                        recipient = dest_conn.get_user(guid=ssub["recipients"][0]["id"])
                                        olog.write( f'\n/*CMDMAN*/ CREATE CACHEUPDATESUBSCRIPTION "{ssub["name"]}"'
                                                + f' FOR OWNER "{recipient["abbreviation"]}"'
                                                + f' SCHEDULE "{ssub["schedules"][0]["name"]}"'
                                                + f' USER "{recipient["abbreviation"]}"'
                                                + f' CONTENT GUID {ssub["contents"][0]["id"]}'
                                                + f' IN PROJECT "{pname}";')

[martinuphoff]

As I said, Developer and Workstation show them all, but with mstrio-py I only get a very limited number of subscriptions. This is also the case when I remove the type check.

[martinuphoff]

Seems like it's a known issue ...

[mgorskiMicroStrategy]

Hi @martinuphoff First of all list_subscriptions() function is not returning every subscription with correct specific type. It means most of the returned subscriptions will have base type Subscription instead od specific one. In this function we distinguish subscription specific type based on delivery type but not every subscription have one.

[mgorskiMicroStrategy]

Hi @martinuphoff Can you please estimate whether you have more than 1000 subscriptions on your environment or not and share this information here?

[martinuphoff]

Hi @mgorskiMicroStrategy, we have around 6000 subscriptions. When I take out the limitation to CacheUpdateSubscription, I get around 900. So I don't think the subscriptions being returned as the base type is the problem.

[mgorskiMicroStrategy]

@martinuphoff thanks for your answer it clears a lot to me. The problem is with chunk by chunk fetching subscriptions mechanism in mstrio-py . It seems that total numer returned by REST is invalid and only first chunk is fetched.

[mgorskiMicroStrategy]

Hi @martinuphoff Can you please also share here environment version and mstrio-py version? You can check mstrio-py version running this code: import mstrio print(mstrio.__version__)

[martinuphoff]

mstrio version is 11.3.12.101 MSTR version is 11.3.12

[NilsSchunk]

Hi @martinuphoff @mgorskiMicroStrategy,

I have the same problem my mstrio version is also 11.3.12.101. Is there maybe any workaround, while the problem is beeing fixed?

Sincerly Nils

[mgorskiMicroStrategy]

@martinuphoff @NilsSchunk At this moment only workaround I can suggest from mstrio-py is fetching subscriptions in one call. First define connection (conn), PROJECT_ID variable and then call api wrapper directly like this: from mstrio.api import subscriptions as subscriptions_api all_subs_direct = subscriptions_api.list_subscriptions(connection=conn, project_id=PROJECT_ID).json()['subscriptions'] This will return list of dicts containing every subscription basic data. You can check id from there and init Subscription object to use methods dedicated for subscriptions. from mstrio.distribution_services import Subscription sub = Subscription(conn, id=all_subs_direct[0]['id'])

[ismailmuller]

I'm here for the same issue:

This is indeed a workaround:

@martinuphoff @NilsSchunk At this moment only workaround I can suggest from mstrio-py is fetching subscriptions in one call. First define connection (conn), PROJECT_ID variable and then call api wrapper directly like this: from mstrio.api import subscriptions as subscriptions_api all_subs_direct = subscriptions_api.list_subscriptions(connection=conn, project_id=PROJECT_ID).json()['subscriptions'] This will return list of dicts containing every subscription basic data. You can check id from there and init Subscription object to use methods dedicated for subscriptions. from mstrio.distribution_services import Subscription sub = Subscription(conn, id=all_subs_direct[0]['id'])

However, the issue that arises using mstrio.distribution_services.list_subscriptions(...) can be reproduced when using limit=None instead of limit=-1 with the "raw" api function mstrio.api.subscriptions.list_subscriptions(...) ==> So it seems to be an issue with the mstrio-py package helper function and not the REST API.

[apiotrowskiMicroStrategy]

Issue resolved. Closing