Handling status with UPA

andy.sciascia
andy.sciascia Contributor
in UPA

If I post a request for an item using UPA and I get a RSSL_MC_REFRESH message with an associated RSSL_DATA_SUSPECT dataState, if the item later recovers I assume that I will get a RSSL_MC_STATUS message with an RSSL_DATA_OK dataState.

Will the code of that message be RSSL_SC_NONE ?

I've checked in the Dev guide but I can't find this case referred to explicitly.

Tagged:

Best Answer

  • Bill Berner
    Bill Berner LSEG
    Answer ✓

    It's okay to look at the state code but the stream state and data state are what tell you the status of your request. Stream state of RSSL_STREAM_CLOSED/CLOSED_RECOVER and data state of RSSL_DATA_SUSPECT tell you that your request is rejected. The state code is just extra information.

Answers

  • brian.sandri
    brian.sandri LSEG

    This will generally be the case, however the status code may vary based on the content provider so it is not advised you code specific behaviors around that. Behavior should be driven mainly by stream and data states. Appendix A in the UPA/ETA Developers Guide walks through typical application behaviors driven by each stream & data state combination, both for item status and group status.

    Hope this helps!

  • andy.sciascia
    andy.sciascia Contributor

    Thank's for that. Re the code, my app needs to know if the symbol we're requesting exists and if we're entitled to it. We have to drive behaviour based on that. We currently use the code field to check this i.e. we check for RSSL_SC_NOT_ENTITLED, RSSL_SC_NOT_FOUND values. It sounds like that isn't recommended. But from when I read in the Dev guide I can't see any other way of checking those conditions.

  • andy.sciascia
    andy.sciascia Contributor

    I understand the point about the state being the vital information. It's just that on our platform it's important to distinguish between a symbol not existing and not being permissioned and we have to use the code for that information. So even though it's recommended in the Dev guide to not use the code to drive behaviour, in this case we have to.

Categories