Hi everyone,

I have few question related to SAP OData service and Gateway Hub.

1. Related to Subscription and Notification.

    When we enable the Subscription check box while creating the service in SEGW, system automatically creates 2 Entity Sets.

    i.  SubscriptionCollection

    ii. NotificationCollection

    I understood the SubscriptionCollection, but what is the use of NotificationCollection.

2. My understanding is that there should a program like /IWBEP/R_MGW_PUSH_TEST to send the push notification. The question is whether the system takes care of sending Notification to the client automatically without writing the push program ?

3. Subscriptions being saved in a Table /IWBEP/D_MGW_SUB.  Now the question is where the notification should save if we have 2 systems/boxes like ERP and NGW Hub.

4. What is the role of bgRFC in the notification process ?

Please share your thoughts.

Thank you.

Ravinder.

I would like to ask if there is any link or place where I can find the current supported features by SAP Gateway for EasyQueries.

if there is a comparison between EasyQuery and direct RFC connection?

I found this link but it provides the entire list of supported features without distinction between EasyQuery and RFC connection.

if all features are supported it that would be great

please explain Model provider class and data provider class?

Introduction

As SAP customers, partners and consultants embark on their journey to designing and building your own Fiori style applications a major part of this journey will be building your own RESTful API’s using SAP Gateway ( OData services ).

I'm going to break down my learning and insights into SAP Gateway development into a series of blogs where I would like to cover the following topics:

• Re-Use and Development Patterns
• Encapsulation of Business Logic & Searching for Entities
• Performance
• eTags for concurrency control

Acknowledgement and Use Cases

The development patterns covered in this series are not originally mine.  If you look at the My Accounts Fiori application delivered by SAP in CRM (UICRM001), this pattern was written to support the OData service "CRM_BUPA_ODATA".

Our colleagues who have put together this pattern probably don't realise how much of a gem it has been for me to rapidly produce re-usable, nicely encapsulated entity implementations in SAP Gateway, so hats off to the folk who put a lot of though and effort behind this.

You can consider this pattern when creating your own OData services in the customer namespace.  For modifying SAP delivered OData services you should always follow the SAP recommended approach and enhancement documentation.

Key Learnings from this article:

• You need someone who understands how to build OData services in SAP Gateway they should know how to leverage re-use patterns to help accelerate UX development and multi-channel consumption.

• You can build a generic template that seeds a base implementation for your concrete entities.

• You can build a module specific abstract object where you can define re-usable functions on a module level (SD, MM, BP for example )

• This is NOT the only way or the standard SAP way of building OData services, I just really like this pattern as it has served me enormously well on a large scale wall to wall Fiori project and I’m hoping to adopt it has a gold standard on future projects I work on and hope it helps you to accelerate your OData service development.

Putting the Pattern Together

First let’s cover our typical OData service from a high level and use a simple entity relationship model as an example ( Account or Business Partner with an Address association ):

SEGW - Design Time.

Here we define our entities, attributes of those entities and association between them ( navigation path ).

In our example we want to look at two entities, Account and Address.  You can generate the entity with various methods but I like to generate new entities from a custom ABAP structure.

• I like to start with a standard SAP structure as an Include ( BUT000 in this example )
• I like to include the term "ODATA" in the naming convention to signify the structure is associated with a REST service that implies restricted use.

DPC, DPC_EXT - Data Provider Classes

These are the classes that are generate from activating the OData service and where you have been told to implement you entity logic for CRUD functions.

I have a couple of rules around DPC_EXT:

• Pass through implementation only for each entity CRUD function to an encapsulated class  
• NO business logic in DPC, this should all be encapsulated in a concrete class
• Function Imports should have their own API, in other words any implementation in EXECUTE_ACTION should be calling some API or utility type class.

Entity Implementation and Class Hierarchy

Most implementations I have seen have a loose encapsulation concept, in other words implementation in CRUD methods in the DPC_EXT class contain some business logic and other business logic is contained somewhere else.

I don’t like this as it becomes difficult to maintain and causes regression problems when new developers take over and add new features.

Instead we can use a nice class hierarchy that helps us encapsulate different business logic in layers. 

This is the current hierarchy I like:

In context with our “Account” entity, this is what we would end up with:

Re-use of Entity Objects

Start thinking about the services you need to build.  Are there re-usable entities across these services? Let’s take a look at a one example.

Below is a diagram that shows two OData services:

• My Accounts Service
• My Sales Order Service

These two services share common entities:

• Account
• Address

In some implementations, I have seen the same code duplicated across different DPC_EXT classes for the same entity which doesn't lend itself to good re-use patterns although there certainly may be a use case where this is necessary.

Here is what I mean about acceleration, once I have the Account and Address entity implementation up and running, tested and stable I can re-use these entities across new services I'm putting together.

The initial build is obviously the longest but scaffolding up a new service with the same entities then becomes considerably faster.

Data Provider Class ( DPC_EXT )

To facilitate this pattern, we need to make some changes in our DPC_EXT. This allows us to access instantiated concrete classes at runtime.

First we need an attribute on our DPC_EXT class that holds the instances of each entity implementation:

The structure of the table is:

Now to instantiate our entity implementations, during the constructor call in the DPC_EXT class we instantiate each entity and store the instance, class name and entity name:

Now we need to call our entity concrete class implementation. Here we assume the service has been generated and you have re-defined the relevant method.

ZCL_ODATA_RT

We've mentioned this class called ZCL_ODATA_RT.  The purpose of this class is to provide:

• Common search capability based on dynamic SQL.  This means when I implement an entity for the first time I can re-use this search pattern that allows me to process complex searches that handles a range of other functions like paging.  In a nutshell we have implemented a re-usable search feature once across all our entity implementations that we can tailor for each concrete class. 

• I can place framework specific functions such as eTag HASH calculations that will work across all of my entities

Overview of Entity Search

The first thing we probably want to do in the Fiori application is search for an entity.  I usually start by building out the generic search pattern in ZCL_ODATA_RT that follows this basic flow:

NB: I don't have to use this when setting up a new concrete class for the first time, I can redefine the GET_ENTITYSET method in the ZCL_ODATA_ACCOUNT and write other code to do the search for us.

Here is an overview of the logic of the GET_ENTITYSET method in ZCL_ODATA_RT:

1) Process paging, max hits and skip tokens.  This allows our dynamic SQL to retrieve our results based on certain filter parameters and then we have a generic paging pattern taken care for us. Think about the Master Object list in a Fiori app where you type in some search criteria and the OData call includes a "substring" filter.

2) Generate a dynamic SQL statement.  This method contains the select, inner join, where statements.

3) Apply additional filters.  Here I can read my entity filters passed by $filter and add additional criteria to our dynamic SQL

4) Execute the dynamic SQL statement and page the results

5) Enrich the data and return the result. This is where where you want to populate additional attributes of the entity that could not be retrieved during the dynamic SQL statement, thing such as texts or formatted names for example.

Implementing the search in our concrete class

I now need to implement this in our concrete class.  When I have created our ZCL_ODATA_ACCOUNT class, I can then redefine the appropriate methods where I need to put my logic, this includes:

• GENERATE_SELECT_FOR_ENTITYSET
• ENRICH_WITH_USER_FILTER (not shown in our basic example below)
• ENRICH_ENTITYSET_DATA

Generate Select

In our generate select method, all we are doing is forming up the dynamic SQL, what attributes we want to select into our entity set.  We can also include joins here if we want to search across multiple tables.

Enrich Entity Set Data

Before we pass the selected entity set records back to the odata framework we want to format and add additional things into the result.  Stuff like full name or texts.  In our example we've just formatted the full name of the business partner into the field FULL_NAME.

We now have a concrete class implementation with an entity set search routine.

Implementing Other CRUD methods

We can then continue to implement the other CRUD functions by redefining the appropriate methods in our concrete class (ZCL_ODATA_ACCOUNT) and data provider class.

Let's do an GET_ENTITY example.  Here is the re-definition in the DPC_EXT class:

And let's put some logic in the ZCL_ODATA_ACCOUNT method GET_ENTITY:

I won't go through POST, DELETE, UPDATE this should provide enough foundation for how the pattern works and encapsulates our business logic nicely into a concrete object.

Summary

In this part of the series we've demonstrated that it is possible to build a re-use pattern that encapsulates our entity implementations cleanly and also include a powerful search feature that we can consume on demand if required without having to re-write the same functions more than once.

I hope you have found this blog useful and see you next time where when we cover some performance considerations for your OData services and e-tag handling for data concurrency control.

Stay tuned for updates as I prepare a set of video walkthroughs to augment the content outlined in part 1 of this series and to show more complex search patterns.

Thanks for stopping by.

Hi All,

I am trying to fetch the value of X-CSRF-Token using the REST client. Any how it always coming blank.. and showing Response Headers has been hidden.

GET is returning required application and executing the service.

"Response headers Headers panel has been hidden"

Please advice how we can get token value or un-hide the panel to get value.

Thanks

Rajesh

Hi,

I´m following this Detailed step by step procedure for Creating Gateway Service with all the CRUD Operations and testing them in Service Explorer Part2 , but in my system I'm having problem with the code generated for the method "MATRSET_DELETE_ENTITY ", this code only mapped the keys fields, and the constants values  , someone knows why?.

My system:

method MATRSET_DELETE_ENTITY.

*-------------------------------------------------------------

*  Data declaration

*-------------------------------------------------------------

  data CLIENTDATA type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPI_MARA.

  data CLIENTDATAX type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPI_MARAX.

  data HEADDATA type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPIMATHEAD.

  data RETURN type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPIRET2.

  data LV_RFC_NAME type TFDIR-FUNCNAME.

  data LV_DESTINATION type RFCDEST.

  data LV_SUBRC type SYST-SUBRC.

  data LV_EXC_MSG type /IWBEP/MGW_BOP_RFC_EXCEP_TEXT.

  data LX_ROOT type ref to CX_ROOT.

DATA ls_converted_keys TYPE ZCL_ZBPS_MATR_DEMO_MPC=>TS_MATR.

DATA lv_source_entity_set_name TYPE string.

DATA lo_dp_facade TYPE REF TO /iwbep/if_mgw_dp_facade.

*-------------------------------------------------------------

*  Map the runtime request to the RFC - Only mapped attributes

*-------------------------------------------------------------

* Get all input information from the technical request context object

* Since DPC works with internal property names and runtime API interface holds external property names

* the process needs to get the all needed input information from the technical request context object

* Get key table information

   io_tech_request_context->get_converted_keys(

     IMPORTING

       es_key_values  = ls_converted_keys ).

* Maps constant value to function module parameters

     CLIENTDATAX-DEL_FLAG = 'X'.

     CLIENTDATAX-MATL_GROUP = 'X'.

* Maps key fields to function module parameters

        HEADDATA-MATERIAL = ls_converted_keys-MATERIAL.

* Get RFC destination

lo_dp_facade = /iwbep/if_mgw_conv_srv_runtime~get_dp_facade( ).

lv_destination = /iwbep/cl_sb_gen_dpc_rt_util=>get_rfc_destination( io_dp_facade = lo_dp_facade ).

*-------------------------------------------------------------

*  Call RFC function module

*-------------------------------------------------------------

lv_rfc_name = 'BAPI_MATERIAL_SAVEDATA'.

if lv_destination is initial or lv_destination eq 'NONE'.

   try.

       call function lv_rfc_name

         exporting

           HEADDATA      =   HEADDATA

           CLIENTDATA    =   CLIENTDATA

           CLIENTDATAX   =   CLIENTDATAX

         importing

           RETURN   =   RETURN

         exceptions

           system_failure = 1000 message lv_exc_msg

           others = 1002.

       lv_subrc = sy-subrc.

*in case of co-deployment the exception is raised and needs to be caught

     catch cx_root into lx_root.

       lv_subrc = 1001.

       lv_exc_msg = lx_root->if_message~get_text( ).

   endtry.

else.

   call function lv_rfc_name destination lv_destination

         exporting

           HEADDATA      =   HEADDATA

           CLIENTDATA    =   CLIENTDATA

           CLIENTDATAX   =   CLIENTDATAX

         importing

           RETURN   =   RETURN

         exceptions

           system_failure         = 1000 message lv_exc_msg

           communication_failure  = 1001 message lv_exc_msg

           others = 1002.

   lv_subrc = sy-subrc.

endif.

*-------------------------------------------------------------

*  Map the RFC response to the caller interface - Only mapped attributes

*-------------------------------------------------------------

*-------------------------------------------------------------

* Error and exception handling

*-------------------------------------------------------------

IF lv_subrc <> 0.

* Execute the RFC exception handling process

   me->/iwbep/if_sb_dpc_comm_services~rfc_exception_handling(

     EXPORTING

       iv_subrc            = lv_subrc

       iv_exp_message_text = lv_exc_msg ).

ENDIF.

IF RETURN IS NOT INITIAL.

* Call RFC call exception handling

   me->/iwbep/if_sb_dpc_comm_services~rfc_save_log(

     EXPORTING

       is_return      = RETURN

       iv_entity_type = iv_entity_name

       it_key_tab     = it_key_tab ).

ENDIF.

* Call RFC commit work

   me->/iwbep/if_sb_dpc_comm_services~commit_work(

          EXPORTING

            iv_rfc_dest = lv_destination

       ) .

   endmethod.

The parameter CLIENTDATA never is populated and i had mapped:

If i'll compare this code with the code generated for the method "MATRSET_UPDATE_ENTITY":

method MATRSET_UPDATE_ENTITY.

*-------------------------------------------------------------

*  Data declaration

*-------------------------------------------------------------

  data CLIENTDATA type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPI_MARA.

  data CLIENTDATAX type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPI_MARAX.

  data HEADDATA type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPIMATHEAD.

  data RETURN type ZIF_BAPI_MATERIAL_SAVEDATA=>BAPIRET2.

  data MATERIALDESCRIPTION  type ZIF_BAPI_MATERIAL_SAVEDATA=>__BAPI_MAKT.

  data LS_MATERIALDESCRIPTION  type line of ZIF_BAPI_MATERIAL_SAVEDATA=>__BAPI_MAKT.

  data LV_RFC_NAME type TFDIR-FUNCNAME.

  data LV_DESTINATION type RFCDEST.

  data LV_SUBRC type SYST-SUBRC.

  data LV_EXC_MSG type /IWBEP/MGW_BOP_RFC_EXCEP_TEXT.

  data LX_ROOT type ref to CX_ROOT.

DATA ls_request_input_data TYPE ZCL_ZBPS_MATR_DEMO_MPC=>TS_MATR.

DATA ls_converted_keys LIKE ER_ENTITY.

DATA lv_source_entity_set_name TYPE string.

DATA lo_dp_facade TYPE REF TO /iwbep/if_mgw_dp_facade.

*-------------------------------------------------------------

*  Map the runtime request to the RFC - Only mapped attributes

*-------------------------------------------------------------

* Get all input information from the technical request context object

* Since DPC works with internal property names and runtime API interface holds external property names

* the process needs to get the all needed input information from the technical request context object

* Get request input data

   io_data_provider->read_entry_data( IMPORTING es_data = ls_request_input_data ).

* Get key table information

   io_tech_request_context->get_converted_keys(

     IMPORTING

       es_key_values  = ls_converted_keys ).

* Maps constant value to function module parameters

     CLIENTDATAX-MATL_GROUP = 'X'.

* Maps key fields to function module parameters

        HEADDATA-MATERIAL = ls_converted_keys-MATERIAL.

* Map request input fields to function module parameters

        CLIENTDATA-base_uom = ls_request_input_data-base_uom.

        CLIENTDATA-matl_group = ls_request_input_data-matl_group.

        HEADDATA-ind_sector = ls_request_input_data-ind_sector.

        HEADDATA-matl_type = ls_request_input_data-matl_type.

        LS_MATERIALDESCRIPTION-langu_iso = ls_request_input_data-langu_iso.

        LS_MATERIALDESCRIPTION-langu = ls_request_input_data-langu.

        LS_MATERIALDESCRIPTION-matl_desc = ls_request_input_data-matl_desc.

* Append lines of table parameters in the function call

   IF LS_MATERIALDESCRIPTION IS NOT INITIAL.

     APPEND LS_MATERIALDESCRIPTION TO MATERIALDESCRIPTION.

   ENDIF.

* Get RFC destination

lo_dp_facade = /iwbep/if_mgw_conv_srv_runtime~get_dp_facade( ).

lv_destination = /iwbep/cl_sb_gen_dpc_rt_util=>get_rfc_destination( io_dp_facade = lo_dp_facade ).

*-------------------------------------------------------------

*  Call RFC function module

*-------------------------------------------------------------

lv_rfc_name = 'BAPI_MATERIAL_SAVEDATA'.

if lv_destination is initial or lv_destination eq 'NONE'.

   try.

       call function lv_rfc_name

         exporting

           HEADDATA      =   HEADDATA

           CLIENTDATA    =   CLIENTDATA

           CLIENTDATAX   =   CLIENTDATAX

         importing

           RETURN   =   RETURN

         tables

           MATERIALDESCRIPTION   =   MATERIALDESCRIPTION

         exceptions

           system_failure = 1000 message lv_exc_msg

           others = 1002.

       lv_subrc = sy-subrc.

*in case of co-deployment the exception is raised and needs to be caught

     catch cx_root into lx_root.

       lv_subrc = 1001.

       lv_exc_msg = lx_root->if_message~get_text( ).

   endtry.

else.

   call function lv_rfc_name destination lv_destination

         exporting

           HEADDATA      =   HEADDATA

           CLIENTDATA    =   CLIENTDATA

           CLIENTDATAX   =   CLIENTDATAX

         importing

           RETURN   =   RETURN

         tables

           MATERIALDESCRIPTION   =   MATERIALDESCRIPTION

         exceptions

           system_failure         = 1000 message lv_exc_msg

           communication_failure  = 1001 message lv_exc_msg

           others = 1002.

   lv_subrc = sy-subrc.

endif.

*-------------------------------------------------------------

*  Map the RFC response to the caller interface - Only mapped attributes

*-------------------------------------------------------------

*-------------------------------------------------------------

* Error and exception handling

*-------------------------------------------------------------

IF lv_subrc <> 0.

* Execute the RFC exception handling process

   me->/iwbep/if_sb_dpc_comm_services~rfc_exception_handling(

     EXPORTING

       iv_subrc            = lv_subrc

       iv_exp_message_text = lv_exc_msg ).

ENDIF.

IF RETURN IS NOT INITIAL.

* Call RFC call exception handling

   me->/iwbep/if_sb_dpc_comm_services~rfc_save_log(

     EXPORTING

       is_return      = RETURN

       iv_entity_type = iv_entity_name

       it_key_tab     = it_key_tab ).

ENDIF.

* Call RFC commit work

   me->/iwbep/if_sb_dpc_comm_services~commit_work(

          EXPORTING

            iv_rfc_dest = lv_destination

       ) .

   endmethod.

All was fine for update method .

There is a BUG in the generator for the method DELETE?.

Best regards.

Hello Experts,

We have an Use Case where in we have iOS Native app that connects to HCP mobile services which connects to back end ECC system (say ERP) via HCP Mobile services and HANA cloud connector (HCC) .

App -> HCPms -> HCC -> OData_SRV -> ERP.

We are able to do a GET with and  without authentication. This Works !! 

However, to perform PATCH operation  from native app, we get an error "CSRF Token needed".

But patch works within SAP gateway if we use tcode /IWFND/GW_CLIENT

For authentication, we are using HCP default identity provider (SAP ID) and HTTP Basic Auth. (and this works too). For backend ECC system we use SAP backend user for identity management.

What is the correct way to configure Cloud connector + backend ECC systems so that we can execute PATCH/update? 

Any pointers will be highly appreciated!!

regards

Akshay

Hi Experts,

When maintaining the Service, after executing entity sets we are getting error RFC Call Ended up Communication Failure Exception.

I have check the RFC all test are working fine. Kindly let me know any parameters is required in RFC for NW gateway to connect.

Our scenario is to create a lead from the company's website when customer enters the registration form. This date needs to create a Lead in our CRM system.

Please help on this...Thanks.

Screen shot attached.

Regards

Varun

Hi folks,

could you please advise me how to generate X-CSRF-Token with GET method. Service call is executed successfully with return code 200, but it is not returning CSRF Token, which I need in my front end for CRUD Operations.

Hi All,

I am updating the External system Service(Sales Force) through REST API's using SAP ABAP. I'm giving the inputs as specified below.

Requested Body in the form Of JSON:

  body = '{ "City" : "Newyork" } '.

     lv_body = body.

Sending Request

  http_client->request->set_header_field( name  = '~request_method'

    value = 'PATCH' ).

while executing the report i am getting the below message in the content field.

[{"message":"The HTTP entity body is required, but this request has no entity body.","errorCode":"JSON_PARSER_ERROR"}]

Please kindly help me on this.

Thanks,

Harikrishna

HI,

I have developed the Annotation project and redefined the method  DEFINE_VOCAB_ANNOTATIONS with below code, how to call the below code in my main service.

My Requirement is to display the description of MATNR as ARTICLE CODE,  Please let me know what I am missing here.

Please let me know if there is any code i have to written to get the

data: lo_ann_target type ref to /iwbep/if_mgw_vocan_ann_target.   " Vocabulary Annotation Target                     "#EC NEEDED

DATA: lo_annotation TYPE REF TO /iwbep/if_mgw_vocan_annotation.   " Vocabulary Annotation                            "#EC NEEDED

DATA: lo_collection TYPE REF TO /iwbep/if_mgw_vocan_collection.   " Vocabulary Annotation Collection                 "#EC NEEDED

DATA: lo_function   TYPE REF TO /iwbep/if_mgw_vocan_function.     " Vocabulary Annotation Function                   "#EC NEEDED

DATA: lo_fun_param  TYPE REF TO /iwbep/if_mgw_vocan_fun_param.    " Vocabulary Annotation Function Parameter         "#EC NEEDED

DATA: lo_property   TYPE REF TO /iwbep/if_mgw_vocan_property.     " Vocabulary Annotation Property                   "#EC NEEDED

DATA: lo_record     TYPE REF TO /iwbep/if_mgw_vocan_record.       " Vocabulary Annotation Record                     "#EC NEEDED

DATA: lo_simp_value TYPE REF TO /iwbep/if_mgw_vocan_simple_val.   " Vocabulary Annotation Simple Value               "#EC NEEDED

DATA: lo_url        TYPE REF TO /iwbep/if_mgw_vocan_url.          " Vocabulary Annotation URL                        "#EC NEEDED

DATA: lo_label_elem TYPE REF TO /iwbep/if_mgw_vocan_label_elem.   " Vocabulary Annotation Labeled Element            "#EC NEEDED

DATA: lo_reference  TYPE REF TO /iwbep/if_mgw_vocan_reference.    " Vocabulary Annotation Reference

*Calling the generated mehtod for creating annotations

     CALL METHOD super->define_vocab_annotations( ).

   lo_reference = vocab_anno_model->create_vocabulary_reference( iv_vocab_id = '/IWBEP/VOC_CORE'

                                                                 iv_vocab_version = '0001').

   lo_reference->create_include( iv_namespace = 'Org.OData.Core.V1' ).

   lo_reference = vocab_anno_model->create_vocabulary_reference( iv_vocab_id = '/IWBEP/VOC_CAPABILITIES'

                                                                 iv_vocab_version = '0001').

   lo_reference->create_include( iv_namespace = 'Org.OData.Capabilities.V1' ).

   lo_reference = vocab_anno_model->create_vocabulary_reference( iv_vocab_id = '/IWBEP/VOC_COMMON'

                                                                 iv_vocab_version = '0001').

   lo_reference->create_include( iv_namespace = 'com.sap.vocabularies.Common.v1' ).

   lo_reference = vocab_anno_model->create_vocabulary_reference( iv_vocab_id = '/IWBEP/VOC_COMMUNICATION'

                                                                 iv_vocab_version = '0001').

   lo_reference->create_include( iv_namespace = 'com.sap.vocabularies.Communication.v1' ).

   lo_reference = vocab_anno_model->create_vocabulary_reference( iv_vocab_id = '/IWBEP/VOC_UI'

                                                                 iv_vocab_version = '0001').

   lo_reference->create_include( iv_namespace = 'com.sap.vocabularies.UI.v1' ).

*Creating the Annotation Target

     lo_ann_target = vocab_anno_model->create_annotations_target( iv_target = 'ZXXX_LINKXXX_SRV.Article' ).

*Creating the LineItem Collection

     lo_annotation = lo_ann_target->create_annotation( iv_term = 'com.sap.vocabularies.UI.v1.LineItem' ).

     lo_collection = lo_annotation->create_collection( ).

**Creating the Records

* Article Number

     lo_record = lo_collection->create_record( iv_record_type = 'com.sap.vocabularies.UI.v1.DataField' ).

     lo_property = lo_record->create_property( iv_property_name = 'Value').

     lo_simp_value = lo_property->create_simple_value( ).

     lo_simp_value->set_path( 'Matnr' ).

     lo_property = lo_record->create_property( iv_property_name = 'Label').

     lo_simp_value = lo_property->create_simple_value( ).

     lo_simp_value->set_string( 'Article Code' ).

Thanks

Shaik

Hi All,

There is a table input in a RFC which has to execute in get_entityset method. $Filter is allowing to take the input into range table but my input table is not a range table.

Is it possible to pass a non-range table data from URL for a gateway service?

Thanks,

Suresh Yerra.

Hi Gurus,

I'm in the data service catalog '/iwfnd/maint_service'.  I'm trying to delete a service that someone created, but it won't let me.  I'm following Delete the Service - SAP Gateway Foundation (SAP_GWFND) - SAP Library , but when I get to the delete service portion, I get 'Service can only be deleted in original system 'SAP'.'.  I'm not sure what I'm doing wrong.  I would appreciate it if someone could give me some direction?

Best regards and thanks for your assistance,

Jim

Hi,

I am trying to solve this runtime error when executing my service from firefox rest client.

I have an entity called Expense Period (ExpPeriod) which has 3 integer fields, zmonth (abap type int2 mapped to Edm.Int16), zyear(abap type int2 mapped to Edm.Int16) and totalamount (CURR13 mapped to Edm.Decimal) in my properties in service builder.

Runtime artifacts are being generated and but it shows following error in response body:

<?xml version="1.0" encoding="utf-8"?>
<errorxmlns="http://schemas.microsoft.com/ado/2007/08/dataservices/metadata">
  <code>/IWFND/CM_BEC/026</code>
  <messagexml:lang="en">RFC Error: Error when converting a numeric field to XML.</message>
  <innererror>
    <transactionid>1B5E32E30AD8F1F4BCAE00155D087807</transactionid>
    <errordetails/>
  </innererror>
</error>

Any ideas?

Hello,

I have a Gateway service setup to receive a photo (as Base64), the service field is typed as Edm.String, the subsequent FM that gets called has an field typed as String as well.

I am pretty sure the Base64 is coming across ok (took the base64 from the request and stuck it in a online converter), what I am trying to do is create a Document based on this jpg.

After some research it seems I am supposed to use:

SSFC_BASE64_DECODE

then

SCMS_XSTRING_TO_BINARY

I am attempting to create this jpg on the server then create the Document from that using

CV120_DOC_GET_APPL

I think the issue is coming after SCMS_XSTRING_TO_BINARY when I am transferring the itab to the dataset.

My code runs successfully, the Document is created and the jpg shows up as part of the Document (confirmed in CV03N), but when I try and open the jpg, I just get the message 'Failed to open document"

Looking for any thoughts or ideas.

-Mike

Hi all,

OData supports query options like $filter=cityfrom eq 'SINGAPORE' or $select=...

(A full list can be found [here|http://www.odata.org/media/16352/%5Bms-odata%5D.pdf])

1) Which options are supported by Gateway?

2) What is the "Gateway Solution" to filter the result of the GetList/Query command for a specific entity?

(e.g. return all flights with city of departure equal to 'Singapore')

Best Regards,

Florian

Dear All

May be a simple question, but not able to get it.

Can someone please explain the steps.

1. I created a ODATA service in the Development Client 103. (development client no data)

     How to use that url - to access data from client 102, (which is a testing client where data is there).

2. Once tested, how to transport the Service to Production system.

    or do i need to recreate it in production system

Regards,

Venkat

Tags edited by: Jitendra Kansal (Moderator)

Hi Experts,

We can import vocabulary file to enable annotations in ODATA. And the technical object 'Annotation' itself is nothing but some tags (name and value pairs) to be added to the metadata file, if I am right. So the vocabulary file is somehing like template to generate some codes in MPC for these tags? and actually the tags like sap:label is also some kind of annotation. And SAP Gateway like the document is to add some SAP prefix tags to the odata file?

Some of my questions:

1 where in the MPC is for the annotation generation? In debug stack, i can only find get_model(). But it looks there is nothing about annotation generation in it.

2 For all the EntitySet settings in SEGW, all the configuration/setting will be transferred into a metadata xml when client access the service? So it is at runtime, all these entityset/properties will be transformed?

3 And is there any document about how to use the standard annotation vocabulary like /IWBEP/VOC_COMMON? For exmaple, if I imported it, I can go to annotation of each property and create a new instance in ValueSet. And set another EntitySet as a search help. But for other thing, i am not sure how to use it. if I want to map a Dropdown in UI5 and I need to set some annotation like sap:text. I have no idea how to set it with annotation file.

Hi Experts,

We have created netweaver gateway services in client 100 but those are not visible in client 200.

Client 200 is test client so we maintained system alias as 200 client.

Also services are not showing in sap netweaver gateway system SEGW tcode but we could see these in /IWFND/MAINT_SERVICE.

Thing is all services are working fine. But I am curious to know why they are not showing in SEGW tcode project list in netweaver gateway and ECC 200 client.?

We have central hub deployment and backend development environment.

Is there something else do we need to do in order to see them?

Hope my question is clear to all.

Thanks

BRS

Hi Experts,

I am new to sap annotation . As far as i know , annotation  can be called by UI as dropdown list or F4 help  .

Currently i want to configure annotation to be used as dropdown list .

In the ui , the description of the field can be seen .

When i filter one value , it can pass its key value to the gateway .

If anyone can answer my question , it will be appreciated.

Or any one can share one example .