Help generating NW Gateway OData service for Z function module

[Former Member]

This will likely be simple to answer for you Gateway guru's, but we have only completed a couple simple Gateway tutorials in our sandbox system.

We need to generate a Gateway service for an existing custom Z function module that accepts 6 string field import parameters and returns an export parameter of a table containing a structure of 11 other string parameters (all import and export parameters are different and unique).  We have encountered numerous errors in trying to implement this similar to the tutorials (that all have better structured models), and need guidance on a workable solution approach.

Ideally the final service solution will take the import parameters as keys and return the export table as a 1 to many array of objects, but we have not been successful at this.

Please any help is greatly appreciated!

Thank you! 

[Former Member · Accepted solution]

Thank you Andre and Ron with the helpful input, and as I'm starting to learn more about Gateway services, you are 100% correct that following effective data modeling guidelines as much as practical for your service model is very important for many architectural reasons!

Please share your thoughts on the following working solution I have implemented that seems to be a reasonable approach when needing to integrate with an existing complex custom functional module like this?

The custom function module exports a table of Bill of Materials data and has material number as one of the import parameters which proved to be very helpful.  So, I modeled and implemented 2 services. 

The parent service is Material with a key of material number and I mapped the GetEntity operation to an SAP standard BAPI to get basic material data (similar to most basic Gateway tutorials).  The child service is BillOfMaterial with a key of material number and I mapped the GetEntitySet operation to the custom BOM function module.  The Material entity has a 1 to many relationship to the BOM entity and therefore created this as an Association with the related Referential Constraint with Material Number keys.  I also created Navigation Property called MatToBOM for the Material entity using the Association noted above.

So, when I generated the services it allows me to access the desired table of BOM data via the custom function module with the following service reference.  Using the association and navigation entity and service capabilities nicely enabled this!

http://MyHost/sap/opu/odata/MyService/Material('12345')/MatToBOM

[Former Member · Accepted solution]

Hi Kevin,

I'm glad you found this helpful and the approach worked for you.

This is exactly the approach I think I'd take. You've correctly identified that there should be a separation of the entities and avoided the 'get everything at once" that a lot of people using RFC's try to implement.

Once you have made this separation by building outside-in, it's then actually easier to make an 'all in one' call by using $expand. Standard $expand needs no extra coding.

What I like about this approach; you supply the simple building blocks and let Gateway take care of the heavy lifting like expanding your request! It's also easier to start adding complexity to your service by using those simple blocks in different ways.

Regards

Ron.

[kammaje_cis · Accepted solution]

Hi Kevin,

The approach looks good.

When you say two services, I hope you mean that two entities within the same service.

Question for you:

What is stopping you from directly using the BOM entity rightaway? something like this.

http://MyHost/sap/opu/odata/MyService/BillOfMaterial('12345')

If it has multiple records for a single material, then something like this.

http://MyHost/sap/opu/odata/MyService/BillOfMaterial?$filter=matnr eq '12345'

This would skip the call to material detail FM.

Thanks

Krishna

[Former Member · Accepted solution]

HI Krishna,

I think Kevin will find this confusing, I certainly do. If he is using key '12345' as his example he won't be using that key to access a BOM, which has a different key.

As for the question "What is stopping you from directly using the BOM entity rightaway?", I'd say "nothing apart from the required use case or common sense". Just because you can do something doesn't mean it's advisable .

The point about 2 services is a valid one, I assume Kevin means 2 entities as well; Kevin, if you'd got a working service with 2 services it would be quite impressive at this stage! That brings us back to the point about not doing things that you can do - you could actually have had 2 services but it would have been more work and harder to understand.

Regards

Ron.

[Former Member · Accepted solution]

Thanks Krishna and Ron,

Originally I hoped to do ".../MyService/BillOfMaterial('12345')" as you suggest, but since my custom function module returns a table, I could not get this direct access to work for the GetEntity operation which only returns a single entity or the GetEntitySet which returns an array but of the parent entity type which didn't align with my BOM entity RFC either.  Guess as a hack work around, I could have added custom code to the _DPC_EXT runtime implementation class, which I started to do but was clearly not leveraging the design and capabilities of the Gateway service components.

I believe the suggestion of "/MyService/BillOfMaterial?$filter=matnr eq '12345'" would have worked, but I was hopeful to avoid passing an extra OData query string like this and provide simpler direct URI access for this basic capability.

Yes my solution of "/MyService/Material('12345')/MatToBOM" is a single service with Material Entity and Operations AND a BOM entity and operations, joined by the association and navigation mentioned earlier.

As you suggest above, I'm learning that establishing a reasonably effective entity data model provides an extensible, maintainable and self describing OData solution which provides many benefits compared to force fitting existing RFCs into Gateway service(s) that do not have an effective underlying model.  I've heard this approach accurately described as ABOS (A Bunch Of Services) instead of delivering on a preferred SOA approach (Service Oriented Architecture).

Thank you both!

[AKMishra]

Hi Kevin, Andre, Ron,

I am trying to create a oData from a function module to use it in SAP UI5 front-end. I am new to Gateway services. Looked at your post, seems to be a similar case to me, but I was unable to understand the logic and flow.

I would appreciate if you could share some in-depth knowledge on how Odata is created for Function Module and exposing the data using RFC connection.

Thank you guys in advance.

Awaiting your response,

Abhishek.

[Andre_Fischer]

Hi Kevin,

did you try also these two tutorials?

How to Develop a Gateway Service using Code based Implementation

in SAP NetWeaver Gateway

How to Develop Query Options for an OData Service Using Code-Based Implementation

in SAP NetWeaver Gateway

Best Regards,

Andre

[Former Member]

Hi Kevin,

I agree with Andre - if you have a customer function module that isn't really an easy fit for your service, then your service model is going to have problems from day 1.

The function module is only an interface pattern as far as the service builder is concerned, the implementation is hidden. I'm inferring that your interface is not suitable for the inside-out approach, like a lot of RFC functions.

What you should be doing is deciding what the service model should look like and build the model. Then adapt the implementation code to fit; this is the code-based implementation approach that Andre has documented. This would mean either replicating the FM internal code within a new data provider or wrapping the function in a data provider that transforms the inputs and outputs properly.

Regards

Ron.