oData developement based on RFC Time management standard BAPI

[Former Member]

Dear experts,

I am exploring Gateway service possiblities by trying to implement an oData service based on RFC. I have choosen a BAPI from R/3 Time Management which is BAPI_EMPATTABS_GETLIST.

That standard BAPI provides time details according to given import parameters (FROM_DATE and TO_DATE) as shown :

I have successfully gone through those steps :

• 1 - Create a project
• 2 - Import data model from RFC BAPI_EMPATTABS_GETLIST
• 3 - Select data source parameters :

Question #1 : is this the correct way to proceed to select both HRTIMESREC_LIST[] and import parameters FROM_DATE and TO_DATE?

Question #2 : what if I would like to use the SEL_EMPLOYEE[] range parameters as well? It seems to create an extra Entity type...

• 4 - Set DOCUMENTNUMER as key :

• 5 - Define default entity set :

• 6 - Define the mapping setting FROM_DATE and TO_DATE as INPUT parameters:

• 

Question #3 : do those parameters allow me to make a ....?filter$fromdate='20151010' post on the base service URL?

• 7 - Generating gives no error : so far so good!
• 8 - Testing with Gateway client gives no result

Any advice?

Thanks,

J.

[AshwinDutt · Accepted solution]

Hello Jeremy,

Both SEL_EMPLOYEE & SEL_ATYPE can be used to pass as ranges as inputs as part of filter parameters.

Please have a look at the QUERY operation implementation which is described below showing how to pass ranges as inputs and you will get an idea how to achieve the same in your case ->

How-ever did you try to debug and see why data is not fetched on firing the service from GW client?

Please debug and see why BAPI is not returning any results for the inputs which you are passing.

Regards,

Ashwin

[Former Member · Accepted solution]

Hi Ashwin,

Thanks for your help that allowed me to deep further on this!

You said that "both SEL_EMPLOYEE & SEL_ATYPE can be used to pass as ranges as inputs as part of filter parameters". But when I select them in my data model, they are part of a separate Entity and I can not select them in my query mapping.

The tuto you adviced is clear on this aspect : do not check SEL_EMPLOYEE[] line... mine is automatically selected as soon as I quote a sub parameter (such as "SIGN" in the exemple below) :

• Tutorial version :

• My implementation :

The consequence is that this element is not available in the same entity set :

Question #1 : Any thoughts...?

Secondly, I have successfully tested my entity set :

Question #2: what is the correct syntax to access my FromDate and ToDate import parameters...?

I have tried this URI :

~/ZWES_EMPATTABS_GETLIST_SRV/DemandesAbsenceSet?$filter=FromDate ge '2009-10-28T00:00:00' and ToDate le '2015-10-30T00:00:00'

... and received an "Invalid parametertype used at function 'ge' (Position: 10)" as a message.

[AshwinDutt · Accepted solution]

Not sure why it selecting that way.

However in that case manually add ' Attendance or Absence Type ' property into the GW model.

While mapping, map this property to the select options SEL_ATYPE.

Please use the below URI ->

.../ZWES_EMPATTABS_GETLIST_SRV/DemandesAbsenceSet?$filter=FromDate ge datetime'2009-10-28T00:00:00' and ToDate le datetime'2015-10-30T00:00:00'

[Former Member]

Thanks to Ashwin I have understood a couple of tricky parts in the usage of the GW Service builder :

• The version I use does not allow to add to a single entity parameter different import parameters (pretty annoying??!? )
  • Solution : add it manually in the Entity Types and define yourself the model...

• If you want to use a range from an import parameters, you can map it directly to your parameter in the Service implementation mapping tool

• The correct syntax to filter on an import parameter type date (such as the date in my exemple) is :
  • /sap/opu/odata/SAP/ZWES_MYWEBSERVICE/NameOfTheSet?$filter=FromDate ge datetime'2009-01-01T00:00:00' and ToDate le datetime'2009-12-31T00:00:00'
  • Make sure your are familiar with the oData syntax... the oData complete convention helped a lot to complete my POST/GET requests.

Ok let's move to the next challenge : do the update, create function and consume it from frontend!