Handling status with UPA

andy.sciascia

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.

Bill Berner

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.

brian.sandri

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

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

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.