Returning Assoc through Web Service

I understand that generally in the _SetSignature method of services, and in the feature name of SDOs, I can use either SDOs or native types as the object type. However the list of objects I'm returning (definitions for a several types of configurable item) would be much easier to look up by-name (rather than having to traverse a list searching for a value), and so a type similar to an Assoc or a C# Dictionary would be most convenient. Specifying "Assoc" in either of the above places just results in an error when I call _GenerateSource though.

Is there any way for a web service to return an object where I can look up values based on a string key?

Find more posts tagged with

Comments

Jason_Smith

In the current version of Content Server there is no way to define a property on an object of type Assoc. So this is the reason SDOs and service definitions use the list structure.

However, defining Assoc properties on objects will be possible in the next version of Content Server. I am looking into changing the data structure of service definitons and SDOs to use an Assoc structure rather than the List structure so that properties have meaningful keys instead of having to know what element in the list refers to what.

Carsten_Kulms

In the meanwhile (until that feature is available) - when implementing your own service - you could design SDO in a way that allows you to store them in a Map object at the client:Have such an SDO have a property "key", return the multiple SDOs in an array, and on the client just iterate once over this array putting each particular SDO instance "sdo" in a Map under the key sdo.key before further processing the service call result on the client. (Yes, this is a workaround but a rather cheap one, I think. Well, this can become annoying if there are maps in maps in maps - I would question such a design though.)

Sam_Archer

Great to hear that it's an upcoming feature. In the meantime, I've actually already implemened a workaround exactly as Carsten suggested. In this particular case, I'm only retrieving the data once at the beginning of a lengthy process, so a little bit of overhead isn't terrible (it's just a tiny bit less clean).

Thanks for the quick responses!