Additional Blogs by SAP
Showing results for 
Search instead for 
Did you mean: 
0 Kudos

Customers and Partners are asking me frequently how to analyze problems related to SMP3 or HPms. Because we were running in such a problem recently I will share here how we handled this kind of situations.


Offline Synchonization (using OData Offline Approach) is not working. The initial Offline DB opening is failing because of an error on the server.


The error message on the client is the first hint. It is saying that the error happened on the server, thus SMP3 should have some more information. Got o Management Cockpit and increase the log level of the corresponding component. In our case I increased the "Offline OData" component to log level "PATH". After that I reproduced the problem and downloaded the ServerLog file.

2016 05 13{SMPARCH-5015-otp-two-factor-authentication=false, SMPSRVRUN3-841-SAML-IdP-proxy=true, SMPARCH-4846-odp-cookie-store=true}##A new database is required for the client |
2016 05 13{SMPARCH-5015-otp-two-factor-authentication=false, SMPSRVRUN3-841-SAML-IdP-proxy=true, SMPARCH-4846-odp-cookie-store=true}##[-100000] An unexpected error occurred while converting the OData metadata to DB metadata: An exception occurred.
Error caused by: An exception occurred. [-100000] An unexpected error occurred while converting the OData metadata to DB metadata: An exception occurred.
Error caused by: An exception occurred.
  at sun.reflect.GeneratedMethodAccessor388.invoke(Unknown Source)
  at sun.reflect.DelegatingMethodAccessorImpl.invoke(
  at java.lang.reflect.Method.invoke(
Caused by: org.apache.olingo.odata2.api.edm.EdmException: An exception occurred.
  at org.apache.olingo.odata2.core.edm.provider.EdmNamedImplProv.getValidatedName(
  at org.apache.olingo.odata2.core.edm.provider.EdmNamedImplProv.<init>(
  at org.apache.olingo.odata2.core.edm.provider.EdmTypedImplProv.<init>(
  at org.apache.olingo.odata2.core.edm.provider.EdmElementImplProv.<init>(
  at org.apache.olingo.odata2.core.edm.provider.EdmPropertyImplProv.<init>(
  at org.apache.olingo.odata2.core.edm.provider.EdmSimplePropertyImplProv.<init>(
  at org.apache.olingo.odata2.core.edm.provider.EdmStructuralTypeImplProv.createProperty(
  at org.apache.olingo.odata2.core.edm.provider.EdmStructuralTypeImplProv.getPropertyInternal(
  at org.apache.olingo.odata2.core.edm.provider.EdmEntityTypeImplProv.getPropertyInternal(
  at org.apache.olingo.odata2.core.edm.provider.EdmStructuralTypeImplProv.getProperty(
  ... 10 common frames omitted
2016 05 13 Exit handle_DownloadData: remoteID=1bb21890-190b-11e6-8000-e7c7deaad8a4 |

Inside the server log you can see that SMP3 found out that a new client database is required for this client (makes sense because it was the initial data sync). SMP3 will then get the metadata document of the corresponding OData server. After that this metadata document will be parsed, and the OData model is used to create the structure of the local client database (e.g. entities will be represented as tables and entity attributes as columns). The MOData Exception telling us that the error occurred inside the Mobilink component which is mainly responsible for synchronization activities. The error: "An unexpected error occurred while converting the OData metadata to DB metadata" shows that the problem should be part of the OData metadata document, because SMP3 was not be able to use this metadata document to create a local db structure.

In our case the metadata document was quite large (more than 50 entities and lots of associations), so it would be good to narrow down the problem a bit. For this we have to have a closer look to the Java stacktrace. Usually especially the "Caused by" part of the stacktrace is interesting, because it will name the methods and classes where the exception got thrown. In our case the method getValidatedName threw the exception in class org.apache.olingo.odata2.core.edm.provider.EdmTypedImplProv. Olingo is the framework used internally to convert Mobilink data and OData. Because Apache Olingo is open source we can even have a look into the source code. Google will point you e.g. to following file: GC: EdmNamedImplProv - org.apache.olingo.odata2.core.edm.provider.EdmNamedImplProv (.java) - GrepCod... . The getValidatedName method is verifying if a given string is fulfilling the following regex expression:


So now let's have a closer look on the metadata document which should cause our problem. We can assume that the problem is related to a malformed value or a value that is containing characters which are not allowed.

Inside one Entity definition we saw a German umlaut in the property's name

<Property Name="Aktivität" Type="Edm.String" Nullable="false" MaxLength="1" sap:label="Aktivität" sap:creatable="false" sap:updatable="false" sap:sortable="false"/>
<Property Name="Notizen" Type="Edm.String" MaxLength="2048" sap:label="Notizen" sap:creatable="false" sap:updatable="false" sap:sortable="false" sap:filterable="false"/>

The sap:label can contain umlauts, but an OData property name must not contain special characters. We can make this sure by testing "Aktivität" against the regex.

after we identified the problem, we simply updated the metadata document in SAP Gateway so that no property value contains special characters. After that the inital client synchronization (=offline db creation) was successful.

This blog post should give you an example on how you can analyze and debug SMP3 server problems.

Process Steps:

1) Increase log level and reproduce problem

2) Carefully check the exception/error message which should be available in the server log

3) Try to understand the Java stacktrace, to identify problem related components, classes and methods

4) Use Google and SCN to find information to this problem

5) After problem identification, solve root cause!

If you still were not able to identify the problem, then open a question in SCN or create an SAP incident ticket. Inside the ticket mention your current server version, explain steps to reproduce the problem and attach the server log.