Service only returning one record, not whole table

[mike_radcliff]

Hello,

I am new to Netweaver Gateway, trying to set up our first Service.

My goal is to use our Solutions Manager (Version 7.02, SP12) system as our Hub and use it to call a Z RFC function RFC on our ECC system (Version 7.31, SP4). We are not planning on installing Gateway on the ECC system yet. The function is written to allow an input variable (Cost Center), and return a table with 4 fields in it(Store, ID, FirstName, LastName). I move the Storenumberin value to the Store output table to be returned so that I can prove the input goes in and can come back in output. I also return test values in the table if nothing is found indicating an error.

The Solutions Manager system has the GW_Core and IW_BEP modules.

I have used SEGW to import the RFC from the ECC system into an Entity Type.

The Entity Type has 4 Properties, StoreNumber, ID, FirstName, LastName (StoreNumberIn is the Input Parameter for the function, and the other 4 are the fields in the output Table). The Property StoreNumber is marked as the Key.

I then created the Entity Set and made it addressable (based on other readings I had done).

I then Generated the Service Implementation.

I then Mapped the Read GetEntity, with StoreNumberIn as Input to the StoreNumber property, and all properties as Output.

I then Mapped the Query GetEntitySet, with StoreNumberIN as input to the Input parameter of the function. I mapped the other 4 fields as Output to their respective function fields. Mapping is the same as Read Mapping.

I then added the service in the IMG (SAP Netweaver/Gateway/OData Channel/Administration/General Settings/Activate and Maintain Services) and made sure it was hooked to the correct System Alias.

I am testing using the Netweaver Service Explorer on the External Service Name.

When I try to Get Entity Sets, I click the entity Set and click Execute. It prompts me for Parameter, and has the Entity Set name there.

If I add ('1234') ( or any other value) to the Entity type, it executes and returns with only one record, the first record of the table. This should not happen.

If i don't add any filter, I get multiple records back.

The way the function is designed, it should ALWAYS return 2 records. It is hardcoded for testing that way for now.

Anyone have any ideas on what I should check?

Any Examples?

Any other discussions or blogs that I have not found yet and should check out?

Most of the ones I have found are all for working on the Local System, Not working doing a generic channel setup to a system that does NOT have Gateway installed.

I need to also return it as JSON. I am using  ?&$format=json   on the call to get it back that way. Is this the best way?

Can we default it to JSON instead of xml?

Thank you for your help,

Mike

[Former Member]

Hi Mike,

It pains me to see yet another beginner start down the RFC road

I avoid this method like the plague and I especially would not write a Z function so that I can use it in an RFC service.

This would be much easier to work with if you made it a code-based implementation, you have full control and are not constrained by an inside-out model. Design your model and code to it, outside-in, not the other way around!

If you are committed to using RFC, I wrote a blog about doing it better.

Regards

Ron.

[kammaje_cis]

Hi Mike,

- If you pass an entityset name with keys, it is called as READ, and it is supposed to return only one record. (Obviously, since you have passed the key)

- If you need multiple records, it has to be only EntitySet name without the keys. That is called as a 'Query'. I am not familiar with "Netweaver Service Explorer" . Why dont you try in a regular browser or Gateway Client or a Browser extention like 'Advanced Est client" for chrome?

- For Json, $format=json, should be good. Other option is to send the HTTP header Accept:Application/json

Thanks

Krishna

[mike_radcliff]

Hi Krishna,

My z function is designed to take in a store number/cost center as input, and return a table containing the first and last names of the people associated with that store number/cost center.

So I have to be able to send in a value, and get a table back.

Your Explanation of Read and Query makes sense, but i cannot seem to create an entity type without a key property?

Am i missing a step?

When I try to import the RFC in data model, it always makes me chose a key?

I have also tried it in a regular browser and it works the same way.

Thanks for the help,

Mike

[kammaje_cis]

Mike,

An Entity as per oData always requires at least one key. I think it makes sense even in any business case. So your entity will have at least one more property in addition to number and cost center as keys. I came to this conclusion since you said that number/cost center pair will not uniquely identify a record.

Since you need multiple entries, you need to run a 'Query'. Now, you use number and cost center as filters for this entity set query.

[mike_radcliff]

Krishna,

I was able to get it to finally work, after your suggestions and some more documentation.

I modified the ECC function to allow for 2 variables as input, Storenumber and EmployeeNumber.

I made the EmployeeNumber return a single record, thereby making it the KEY to my function. I added logic to return the Storenumber employees also. I also ensured the input variables had the same name as the table variables that were returned.

I then redid the project. I used the Storenumber, EmployeeNumber, LastName and FirstName as the fields on my Entity Type, and made EmployeeNumber the Key and StoreNumber to be a filter.

I then mapped the Read to have the EmployeeNumber as Input and Output.

I then mapped the Query to have both EmployeeNumber and StoreNumber as Input, to the appropriate import variables.

Therefore when I call it with ('123456'), it triggers the Read service and uses that number as the key and returns a single value.

When I call with ?$filter=StoreNumber eq '1234', it returns the proper records by using the query.

So it is working great now, but it took some more digging.

Thanks for the help,

Mike