cancel
Showing results for 
Search instead for 
Did you mean: 

Understanding SAP Gateway and Service Creation

Former Member
0 Kudos

Greetings everybody.

Currently I'm working as a junior ABAP developer for a Retail Company where they plan to implement a SAP FIORI Application for Warehouse Management. I was given the task to generate a set of custom RFCs to emulate a few WM transactions in order to fullfil this requierement, which I have finished now, the next step is to generate the services via SAP Netweaver Gateway which is already up and running and configured for this.

I have a few questions regarding about the concept of service creation via transaction SEGW. I have read a few tutorials and tried to do some testing, however I have stumbled myself with a lot of issues trying to understand the very concept of the service creation.

So I want to ask to you experts for some insight to understand this.

First, I have, as mentioned above, created a set of RFCs to mimic some standar WM Transactions, the issue I have right now is this.

I created my project, and created a data model importing my ZRFC model, for example, this RFC has 5 Import Parameters, 2 are marked obligatory, 3 are optional, 1 exporting and 1 table which contains the result, which in this case is a table with Current Stock.

As far as my understanding goes, when I do the importing, I should only map the output table fields and ignore the importing parameters for the mapping. My doubt is, this mapping represents what the service will give as an output or since it's based on a RFC it will also mean that it will implement the logic for the process?

My other issue understanding is how I can define which fields will be Key, since my RFC already implements the logic for the data fetching / processing from the corresponding ECC tables, having a key doesn't make much sense to me, so I'm curious what does this Key works.

Lastly, I don't quite have to implement the CRUDQ functions, in most cases my RFCs already perform the corresponding operations like giving a table output or creating WM documents / operations such as Material Documents, Picking, and Order Confirmations, so the question in this case would be, should I create a custom service implementation for my RFCs or what criteria should I follow to fit them in any of the CRUD operations?

I'm just trying to get some understanding on how I should design my services or some insight if the approach we have is the most appropiate.

I will keep trying to get some reading done and get a deeper understanding on this, however I will be really greatful for any insight you guys could provide me with.

Thank you all in advance.

Cheers.

Accepted Solutions (1)

Accepted Solutions (1)

AshwinDutt
Active Contributor
0 Kudos

Hello Emmanuel,

1.


As far as my understanding goes, when I do the importing, I should only map the output table fields and ignore the importing parameters for the mapping. My doubt is, this mapping represents what the service will give as an output or since it's based on a RFC it will also mean that it will implement the logic for the process?

At the initial stage RFC is imported to create your Data Model i.e., Entities. While importing you can select the fields which are only required for your scenario i.e., inputs and also outputs needed for your scenario.

Mapping depends on your requirement/scenario.

If you want only the output of RFC with out sending any input, then do not map the input parameters. Map only output.

If you want to send some input and get output based on it then map both input and output.

Regarding implementing the logic, GW will not implement any logic by its own.

In your case RFC itself has some logic written inside it and this RFC will be called by GW frame work. During run-time inputs which are passed as part of URL, frame work picks those and passes these input parameters to your RFC ( Passes only the parameters which are mapped as input in GW level ) and captures the output response from it ( Parameters which are only mapped as part of output in GW level ) and give to the application in requested format ( JSON or XML )

2.


My other issue understanding is how I can define which fields will be Key, since my RFC already implements the logic for the data fetching / processing from the corresponding ECC tables, having a key doesn't make much sense to me, so I'm curious what does this Key works.

These Keys are for the GW Model.

Every entity created as part of GW Model should have at-least ONE parameter defined as a Key.

You can have more than one parameter defined as Keys as well.

Again this Depends on your scenario.

Examples :

Assume in RFC level Material & Plant are not mandatory parameters.

Your RFC may be capable of

a. Take Material Number and Plant and send the matching record.

b. Can send all the records with out passing any Material number and Plant.

Example 1->

Assume my scenario in the application is user get the below output based on the input.

Input : Material Number

Output : Material Number, Material Type, Material Description

So in the GW Model i will make Material Number as KEY because i want user in the application to enter material and search.

Example 2 ->

Assume my scenario in the application is user get the below output based on the inputs.

Input : Material Number, Plant

Output : Material Number, Material Type, Material Description

So in the GW Model i will make both Material Number & Plant as KEY's because i want user in the application to enter Material & plant and then search.

3.


Lastly, I don't quite have to implement the CRUDQ functions, in most cases my RFCs already perform the corresponding operations like giving a table output or creating WM documents / operations such as Material Documents, Picking, and Order Confirmations, so the question in this case would be, should I create a custom service implementation for my RFCs or what criteria should I follow to fit them in any of the CRUD operations?

RFC's which are developed for Create / Read / Update / Delete operations are wrapped as part of  GW Service by implementing Create_Entity / Get_EntitySet or Get_Entity / Update_Entity / Delete_Entity method respectively.

We implement the above methods in GW Level and call our RFC's performing CRUD accordingly.

All you need to do is go to SEGW T-Code, define the input / output parameters in GW Model, Perform Mapping of those input/output parameters to RFC in the service implementation step ( Can be C / U / R / D ).

Generate run-time objects, Register service and Consume it.

You can also just create Data Model in SEGW ( with out any mapping ) and generate the run-time objects.

Once objects are created successfully, go to DPC_EXT class and redefine the required Create/Read/Update/Delete Method and manually call the RFC or write the Logic. Activate class.

Register service and Consume it.

Refer ->

Development Approaches - SAP NetWeaver Gateway - SAP Library

Entity Types - SAP NetWeaver Gateway Foundation (SAP_GWFND) - SAP Library

Regards,

Ashwin

Former Member
0 Kudos

Thank you very much Ashwin, this was the kind of explanation I was looking for.

I will do some reading with the provided links, Thank you very much.

Edit:

I'm getting the grip of this transaction now, however I've found one more issue:

When doing the Query function for my app, guides indicate that every input field should have an output direction, however I've got this:

The two top fields, IvAlmacen and IvTipoalmacen are two fields that help me doing some filtering in my RFC, however these fields are not mappend into the generated table, therefore I keep getting the error message : "Key Field X does not have an Output mapping for query operation", the question then is, should I have to modify my table to get such fields as well or there's some other way to workaround this. Even more, these 2 fields should always have to have a value in order to proceed the operation, the other 3 are optional but at least 1 should have a value, else an error message would be sent into EvMessages.

Is there a way to work around this?

Answers (1)

Answers (1)

kedarT
Active Contributor
0 Kudos

HI Emmanuel,

Look at these blogs:

Hope this helps.

Former Member
0 Kudos

Thank you for the link. I did go over these links in order to understand the service generation, however I'm unable to get some things right.

If I understood it correctly, on the first part in step 4 he uses the RFC to build the table that will contain the information obtained in a further step, no Inputs will or should be mapped in this step? Is this a correct approach?

And then further, on the second part step 1, he creates the logic to fetch the information and fill up the table by using the same BAPI / RFC. Is that right?

Now my issue regarding this is, in my particular case, as I said, I have a RFC that does what transaction LX03 does for WM to an extent. I have 5 inputs, 2 of them are marked as Obligatory, such as Warehouse Number and Warehouse Type, and user can filter or generate the table by giving as input either a Material Number, a Bin and or a Batch, this should generate a table with the information corresponding to Material Stock.

My problem is I'm having a hard time understanding how I should map these inputs as in the example before he doesn't deal with any inputs from the RFC itself but the ones he created.

Anyway I do thank you for the links.

Cheers