SAP ODATA V2 Transport and Troubleshooting Guide
SAP ODATA V2 Transport and Troubleshooting Guide
ODATA V2 SERVICE
TRANSPORTS & TROUBLE-
SHOOTING GUIDE
SAP NetWeaver 7.5 and higher
SAP S/4HANA On-Premise
Madhusudhan Sangam
Document History
2
TABLE OF CONTENTS
3
Abstract
Chapter 1 – Introduction
1.1. Overview of the Architecture
1.2. Prerequisites
4
Chapter 1
Introduction
Welcome to “ODATA V2 Service Transports and Trouble-shooting Guide” for SAP NetWeaver 7.4/7.5 and SAP
S/4HANA On-Premise systems. In this whitepaper we will introduce you how to transport a Standard OData service
and Custom OData Service from one system to another system. We will also show you trouble shooting steps on
how to resolve issues that appeared after transporting ODATA service. We will show you the TADIR objects that
are required to transport for any ODATA Service.
Before we can start our configuration, we need to look at the Architecture that this whitepaper will address. This
whitepaper will cover the following scenario:
• Transporting Standard OData service
• Creating and transporting Custom ODATA Service
Transport Architecture:
To transport any OData service, we need a Workbench request and a package to carry the TADIR objects
Hub and Embedded Environment:
For Hub and Environment system, we need to create work bench requests and package in frontend system.
Transport requests and package need to be transported from source system to target system.
We need following details to achieve this functionality
• Workbench request
• Package
Source Transpor
t
Target
System System
5
If your target system is Hub environment and source is Embedded
system, then transport the workbench request into target front
end system.
Note
If your target system is Embedded environment and source is Hub
system, then transport the Front-end workbench request into
target embedded system.
Prerequisites
6
Chapter 2
Creating Transports and Packages
The system administrator must create the workbench request and package in the frontend system before
registering any OData service.
Workbench request is needed while registering any OData service when Z* package is selected
To create Workbench Request, do the following:
1. Login to the SAP Gateway system and execute SE01 t-code
2. Click on “Create…” Icon and select Workbench request
7
3. Fill-in the required information and click on Save
4. Click on Transports tab and Click on display to see whether the workbench requests got created
8
3. Fill-in the required information and click on Save
Creating Package
4. It will throw a new screen to create a package, click on yes to create the package
9
5. Fill-in the required information and click on continue
6. A prompt will be displayed requesting a workbench request to be specified. Click on the Own Requests
and select the Workbench request that you created
7. Click on Continue
8. Now execute SE01 t-code and enter the Workbench request id
10
9. Click on “Display” and expand the task that created under Workbench request, you will find the package
saved into this workbench request
11
Chapter 3
Handling Standard OData Service Transport Objects
In this chapter, we are going to show you required TADIR objects for a Standard OData Service and how to
manually include these objects in a transport request. Also, we will show you how to change the package for OData
Service objects. For any Standard OData Service, we don’t need to transport the entire ODATA project (MPC,
MPC_EXT, DPC, DPC_EXT classes). Because all these classes and runtime artifacts would come with components.
Standard OData Service TADIR Objects:
Short Description Program ID Object Type Object Name
Package R3TR DEVC Z***_PKG
SAP Gateway: Model R3TR IWSG Z<Service
Metadata Group>_SRV_0001
SAP Gateway: Service R3TR IWOM Z<Service model
Groups Metadata name>_MDL_0001_BE
ICF Service R3TR SICF <System ID>*******
To save any small change into transport request, client need to open for modifications and following changes
need to be made in your SAP NetWeaver System
To enable the client changes in your system, do the following
1. Login to SAP Gateway system and execute SCC4 t-code
2. Click on Edit and double click on the client that you are going to make changes
3. “Automatic recording of changes” option need to be selected under Changes and Transports for Client-
Specific Objects
4. “Changes to repository and cross-client customizing allowed” option need to be selected under Cross-
Client Object Changes drop down
12
If you didn’t get any error and changes are not saved into
transport request means that above changes are not made in
Note your system
For Hub Environment users follow the above section and enable
the changes in front-end & back-end system
In this section we will go through all the steps that are to prepare the primary server for the Cockpit in order to
enable replication.
3. Select the System Alias, and click on “Get Services”, we will see the services like below image
13
4. Now search for the service that you want to register, click on Add Selected Services
5. Enter the package name that we created in chapter 2 and click on Continue
14
6. In next screen, we will get a prompt to select work bench request. Select the work bench request that
we created in chapter 2
8. Click on Continue, we will get Services was created and its metadata was loaded successfully message in
next screen
9. Now execute /nSE01 t-code, to see whether the OData Services objects are saved in a request or not
10. Enter the Workbench request number and click on display
15
11. Expand the request and task that is created in request, we will find package, Model Metadata, Service
Groups Metadata, ICF Service of OData Service
Workbench requests will only transport the ICF nodes, but these nodes
need to be activated in target system. Due to security reasons, workbench
request cannot transport ICF Node Activation
Note
System alias will not be recorded in transport request. We need to open
the client and system in target system to add system alias in target system.
Or perform the below sections steps to transport system alias
System alias is a client-specific, so it is captured in Customizing request instead of work bench request.
To capture system alias in transport request, do the following
1. Login to SAP NetWeaver and execute /n/IWFND/MAINT_SERVICE t-code
2. Search for the service that we registered and double click on it
3. If the system alias is present, click on Remove System Alias
16
4. Click on “Add System Alias”
7. We will get a screen “Prompt for customizing request”, select the customizing request that we created
in previous section,
8. Click on Continue
9. Now go to SE01 t-code and check this alias is captured in customizing request or not
17
10. Enter the customizing request and click on “Display”
Now, the standard OData Service is ready to transport. Make sure this transport request is imported in target
system. Also, make sure that your target system is opened in SE06 as well.
18
Deleting OData Service
In this section, we will show how to delete/de-register OData Service from Service Catalog
screen(/n/IWFND/MAINT_SERVICE). OData Service that is transported cannot be deleted in Target system. We
need to delete the service and capture the changes in a Transport request.
To delete OData Service, do the following
1. Login to SAP NetWeaver and execute /n/IWFND/MAINT_SERVICE t-code
2. Double click on the service that you would like to delete, click on “Remove System Alias”
4. Select the workbench request to save the ICF Node deletion changes
5. Click on Delete Service and click on “Yes”
Go to SE01 and check the workbench request, it will have IWSG, SICF, and IWOM TADIR objects. These service
deletion changes, transport this to Target system to delete any service in target system.
19
Chapter 4
Handling Custom OData Service Transport Objects
In this chapter we will show how to create a custom OData Service using SEGW t-code, we will show you list of
transportable objects and tables that need to be handled from one system to another system.
In this section, we will show a simple custom OData Service that contains single entity set which is imported from
an existing DDIC structure. We need Z* package and workbench request to transport this service into another
system. We request you to follow the chapter 2 on how to create transport requests and packages.
To create custom OData Service using SEGW, do the following
1. Login to SAP NetWeaver and execute SEGW t-code
2. Click on “Create Project”
20
4. Right-click on the Data Model and click on “Import→DDIC Structure”
5. Enter the Entity Name and select the DDIC Structure, click on Next
21
6. Select the properties and click on Next
22
8. Sales Entity and entity set are added to the project which need to be generated, click on “Generate
Runtime Objects”
9. You will see workbench selection screen, select the workbench request and click on continue
10. In next screen, you will see the classes that are generated for this project. Click on Continue
23
11. In next screen, select the package and click on Save
12. In next screen, select the same workbench request and click on continue
13. We will see Model and Data Provided classes generated successful messages
24
14. Let us go and check the work bench request where this project is saved, we will see the following entries
Now, this transport request has the entire custom project. Transporting this request will not display the service
on service catalog screen (/n/IWFND/MAINT_SERVICE). We need to capture the service registration objects also
in this transport request, which is we showed in chapter 3 (Registering Standard OData Service in a Transport
Request). After following the section 3.2, we will have the following objects in this request (please see the below
screenshot)
25
List of TADIR Objects Custom OData Service is associated
In this section, we will demonstrate what TADIR objects that we need to take care of when it comes to
transporting custom OData Service.
26
R3TR IWSV ZCUSTOM_V2_ODATA_SRV Business Suite
Enablement- Service
27
Chapter 5
Troubleshooting Guide
When registering an OData Service, we might have selected $TMP package accidentally/when creating custom
OData Service, we might have selected $TMP package. When $TMP package is selected, OData Service objects
will not be saved in any transport request. Hence, we cannot transport the OData Service that is saved in $TMP
package. We have two options here; we need to delete the OData Service and then recreate/register the service
by following the above-mentioned steps or change package for OData Service objects by following below
mentioned steps.
For any Standard OData Service, we need following TADIR objects
Short Description Program ID Object Type
SAP Gateway: Model R3TR IWSG
Metadata
SAP Gateway: Service R3TR IWOM
Groups Metadata
ICF Service R3TR SICF
For any Custom OData Service, kindly go to the chapter 4 (List of TADIR Objects Custom OData Service is
associated)
To change the package for OData Service objects, do the following
1. Login to SAP Gateway system and execute SE03 t-code
2. Click on “Change Object Directory Entries” and click on Execute
3. Enter “IWSG” and hit enter, it will automatically populate the Program ID and description
28
4. Enter the Obj Name (Example: if the service is ESH_SEARCH_SRV, object name would be
ZESH_SEARCH_SRV_0001)
5. Repeat step 3 and 4 for IWOM and SICF Objects (For IWOM if the service is ESH_SERVICE_SRV, object
name would be ZESH_SEARCH_MDL_0001_BE, ICF node is unique one which you can find in SICF t-code
object directory entry), click on “Execute”
29
7. We will get below screen to change the package, enter the package name or select the package using
value added field
8. Click on Save, we will get another screen “Prompt for local workbench request” select the workbench
request that you want to transport and click on Continue
9. If the object is changed into different package, then we will see a screen like below
10. Repeat the steps 6,7, and 8 for IWSG, SICF objects as well.
11. Execute SE01 t-code to check whether these entries are saved in a request
30
12. These objects are saved in Development/Correction under the request, this is because we manually
included these objects in request
In this section, we will show you on how to include OData Service objects in a transport Request. For Standard
OData Service we need IWSG, IWOM and SICF objects. For custom OData Services we need the list of objects that
mentioned in chapter 4 (List of TADIR Objects Custom OData Service is associated)
31
3. Select the radio button of “Selected Objects” in next screen
]
5. Click on “In Request” and select the workbench request in next screen
6. Click on Continue, you will see a message at bottom of the screen “All objects were placed in request”
After transporting an OData service, it is missing in service catalog screen (/n/IWFND/MAINT_SERVICE). This issue
appears when IWSG TADIR object is missing in target system.
32
Firstly, we must find in which request this object is present. If this object is present in a workbench request, check
whether this request is released, transported and imported into your target system.
4. Click on Execute, we will get the workbench request id and status of it (note down the request id)
5. If the workbench request is not released, execute SE01 t-code and enter the workbench request number
that we noted in previous step
33
6. Click on “Display”, check Model Metadata, Service groups Metadata, and ICF Service is present in
request like below
Release this request and transport it the target system. After transporting make sure this request is imported
into the target system.
This issue appears when IWMO object might be missing in a transport request/IWMO object have been
transported but the table entries are missing in Target system. This issue rarely appears and more chance to
appear in BEX query related services or CDS related services. To resolve this issue, transport the following table
entries from source system to target system
/IWBEP/I_MGW_SRG
/IWBEP/I_MGW_SRH
/IWBEP/I_MGW_SRT
/IWBEP/I_MGW_OHT
/IWBEP/I_MGW_OHD
Entity Sets in OData Service throws “No values found” after the transport
This issue appears when authorization value of an OData Service is missing in target system. Another symptom for
this issue is, when we execute the service it works fine and when we execute the service with $metadata it won’t
show any entitysets that are present in this service.
To resolve this issue, we need to transport the authorization value of OData Service which is present in USOBHASH
table. For any OData service (Standard/Custom) there will be authorization value associated to it we can find this
in USOBHASH table and assign that to S_SERVICE authorization object.
This issue appears when we try to delete an OData Service which is transported/ an OData Service which has SAP
system id. For transported service, we need to delete the service in source system and then we need to carry these
deletion changes to target system in a transport request.
Kindly follow the below steps if you cannot transport the deletion changes or if you are getting the issue ‘Service
can only be deleted in Original system’ SAP
34
1. Login to SAP NetWeaver and execute SE03 t-code
2. Double click on “Change Object Directory Entries”
3. For any OData service we need to change the system id for following objects to remove the service
registration
35
4. Click on Execute, place the cursor on each object and click on “Object Directory”
5. Change the system id to current system for all the objects and click on “Save”
6. After changing the system, execute /n/IWFND/MAINT_SERVICE t-code and try to delete the service
Custom OData Service throws error: An Exception was raised in target system
This issue appears for Custom OData Services mostly, to resolve this issue kindly follow the steps that mentioned
in SAP KBA 3029413
36
Transported OData Service throws error “No Service found for Namespace”
This issue appears for Custom OData Services mostly, this is because of IWMO object is missing in your workbench
request. Kindly refer chapter 5 (How to Manually include OData Service objects in Transport Request) and include
the object R3TR IWMO **** in workbench request and transport it to target system.
If this issue appears in standard OData Service, that means IWMO object have been deleted externally by a user.
Either we need to re-create this object in target system by following SAP KBA 2930655 or we need to transport
this from source system by changing the package from standard to custom package for IWMO object.
37