Creating OData for REST service having Complex Datatype

[Former Member]

I have followed and was able to retrieve data from REST Service.

We have a rest service that returns the following xml :

so I have created a following OData model:

Pages is a complex type of pages. pages.item is also complex type of item.

I deploy this service after adding the Javascript code.

But when i run this service on SMP Gateway I get the following Data:

If you see, I only get the Last Data item that exist in the service.

<d:vcKey>YMA85X-APIL</d:vcKey>........

So what can be done to get the complete data set of items?

[CarlosRoggan]

Hello Nikhil,

As far as I understand your scenario, the model doesn’t match perfectly.
The “item” is a property and a property has only one value.
What you’re thinking about is to have item as a property that is a LIST of values.
In the OData Model Editor, you cannot specify the “item” to be of type “Collection(ComplexType)”
So you would need to chande the model
The list of “item” instances would be an entityset and you would need an EntityType for the “item”
Then you would model a navigation from UserAttrValue to its “Items”, a one-to-many navigation
(maybe you can skip the “pages”, if it doesn’t contain further data?)

Does this help?

Kind Regards,
Carlos

[Former Member]

I created this model after you suggested it.

But the data I get in return is :

As you see I don't get data for Pages.

I have not assigned any data-source for item entity set.

Do i have to add it? If yes, what should be the service URL for the same.

Does anything need to be changed in the Javascript?

[CarlosRoggan]

Hi Nikhil,

the point is that odata doesn't support to address a resource that has a property that is a list.

Which would be your case.

So you have to workaround it.

One workaround would be to stay with the current approach of having only one EntityType and put all the information of all "items" into one String property (concatenated) and let the consuming application extract the details out of it. Not nice.

So I proposed the second workaround.

You have 2 lists, the userattr and the items.

For one instance if userattr, you can navigate to the items that correspond to it.

In OData, there's a concept of merging these 2 lists with one GET request, by using $expand.

But $expand can only be used if there's a navigation.

I think that $expand is not supported for REST data source (will check the docu).

However, the application that consumes your OData service, will have to do 2 calls:

First the GET request to the UserAttr, then the GET request for the list of items corresponding to this UserAttr.

(Maybe both calls can then executed in one $batch call)

OK

You've now the navigation in your model.

Now you need to implement your workaround.

At the end, you have the same URL in your backend-REST service, and you would use it for both calls to the OData service. Unfortunately, you lose performance here.

So you would assign the same URI to both EntitySets in Eclipse.

You have to write the custom scripts such that the first one provides the UserAttr and the second one provides the list of items along with the 2 properties

I think this answers your question why you don't get the items: you need to follow the navigation and in the second call, you get the items for the given instance of UserAttr

In your second script, the item-entityset, you have to provide exactly the list of items that correspond to the selected UserAttr, which is the one that is in the URL.
E.g. <host><service>/UserAttrSet('123')/NavPropToItems

In your script, you have to retrieve the instance of UserAttr('123'), the info is in the uriInfo object.

You can follow below tutorial to learn how to implement navigation:
http://scn.sap.com/community/developer-center/mobility-platform/blog/2015/04/23/integration-gateway-...

This tutorial has a REST service that actually has navigation. Your REST service doesn't, so you can not apply 1 to 1 to your case.

You can use it just to learn about the API.

In your case, your second script gets invoked for an OData-URI like
<service>/UserAttrSet('123')/NavPropToItem

then you have to modify the relativeURI-header in the method processRequestData such that the URL that is used to call the REST-backend-service is the same like it was for the first script.

Then, extract the items from the payload and return only these

You will need to try out and play with scriptings...

I hope all this is understandable and will help you...;-)

If you know a public REST service with the same structure like yours, I could try it and write a Blog post here in SCN.

Kind Regards,

Carlos

[Jitendra_Kansal]

Lets hear from