Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [om2m-dev] OM2M-problème rencontré


To better understand your problem, can you test the following scenario which includes 2 applications created on different SCL:

a) Start a NSCL on
b) Start a GSCL on
Make sure that the GSCL and NSCL are mutually authenticated (use the web interface).

1) Create SENSOR application with a DATA container on the GSCL.
2) Create MONITOR application with a DATA container on the NSCL.
3) Subscribe MONITOR to SENSOR using the following request:


<om2m:subscription xmlns:om2m="">

4) Create a contentInstance event on the DATA container of SENSOR application.
5) The MONITOR should receive the new event as notification on its DATA container. Check it using the fowling request:


Does this scenario work for you ?


Le 18/06/2014 00:20, Feifei Liu a écrit :
Hello Mr. Ben Alaya,

Thank you very much for your response. Now I understand better about the concept of the Base URI and the Target URI.

I tried the method that you gave me, but I didn't get the expected result. In fact, I don't understand the method: notify(RequestIndication) in the class Notifier(package:org.eclipse.om2m.core.notifier). In the method, no matter which scenario it is, the target ID is set to "null". It is here that cause the problem.

public static ResponseConfirm notify(RequestIndication requestIndication){
            return new RestClient().sendRequest(requestIndication);
            String sclId = requestIndication.getTargetID().split("/")[0];
                    String appId = requestIndication.getTargetID().split("applications/")[1];
                    Application application = DAOFactory.getApplicationDAO().find(Constants.SCL_ID+"/applications/"+appId);
                    return new RestClient().sendRequest(requestIndication);
                return new Redirector().retarget(requestIndication);

 I put the protocol-independent URI as the contact during the creation of the subscription : /nscl/applications/LampApp/containers/TestToReceiveFil/contentInstances.

But the destination URI of the notification message is always a combination of the "Base URI" and the " Target URI" , something like: /nscl/applications/LampApp/con

I am blocked here . Could you please help me to solve this problem?
Thank you for your help.

Best Regards,
Feifei LIU

-------- Original Message --------
Subject:        Re: OM2M-problème rencontré
Date:   Sat, 14 Jun 2014 14:34:17 +0200
From:   Mahdi Ben Alaya <ben.alaya@xxxxxxx>
To:     LIU Feifei <feifei.liu@xxxxxxxxxxxx>
CC:     ybanouar@xxxxxxx <ybanouar@xxxxxxx>, Thierry Monteil <monteil@xxxxxxx>

Hello Liu,

You can use our mailing list for future questions, our team will be
happy to answer you. (subscribe here
OM2M implements three subscription/notification scenarios: *

Scenario 1 (Your scenario)*
You should use a *protocol-independent* contact URI when you create a
subscription for an Application:
The GSCL is able to build automatically the full URI based on the "nscl"
stored information using the re-targeting mechanism.

Create subscription Request example:

<?xml version="1.0" encoding="UTF-8"?>
<om2m:subscription xmlns:tns=""
xmlns:xsi="" >

To answer you question related to the "RequestIndication" class, let's
consider the following request:
GET protocol://ip:port/context/path/to/resource

The "base" attribute contains the first part of a URI
(protocol-dependent): protocol://ip:port/context
The "targetID" attribute contains the second part of a URI
(protocol-independent) : path/to/resource

The OM2M core plugin handles protocol-independent requests to make easy
their mapping to specific communication protocols such as HTTP and COAP
(COAP binding will be published soon)

*Scenario 2: *
It is also possible to start an independent server (e.g. listening on and use it as contact URI for
In that case the GSCL will send directly notification to that specific
Remarque: In this example the specific server ip should be reachable by
the GSCL.
See this tutorial:

*Scenario 3:*
If the specific server is not reachable by the GSCL, you can add the
specific listening address as "aPoc" on the subscribed application
representation like this:

Create application Request example:
POST <nscl-ip>:<port>/om2m/nscl/applications

<om2m:application xmlns:om2m="" appId="appTest">

Then, you can create a subscription with the URI of the application as
contact URI (the application URI is protocol-independent). In that case
The GSCL is able to re-target notifications to the right NSCL. Finally
the NSCL will notify the specific listening server based on the aPoC tag.

Create subscription Request example:

<?xml version="1.0" encoding="UTF-8"?>
    <om2m:subscription xmlns:tns=""
xmlns:xsi="" >
*  <**om2m:contact>**nscl/applications/**appTest**</tns:**om2m>*

Don't hesitate to contact us if you have any question or remark.

Best regard,

Le 13/06/2014 19:20, LIU Feifei a écrit :

Bonjour Messieurs,

Je travaille actuellement au sein de Sagemcom et je suis en train de
utiliser votre open source OM2M. Pendant l'utilisation, j'ai rencontré
un problème sur le plateforme NSCL.

Contexte: Une application NA qui est enregistré auprès de nsclBase.
Deux containers dans cette application sont créés. Container 1 est
pour déposer le fichier XML sur le serveur. Container 2 est pour
tester le suscription. Il est un « subscriber » de container 1. Quand
je créée une containerInstance pour container 1, container 1  va
envoyer une notification au container 2  avec la destination défini
dans le "contact" de suscription. Ici, j'ai

voici le résultat:
1. INFO: Notification Request:
version="1.0" encoding="UTF-8" standalone="yes"?>

2. INFO: RequestIndication
representation=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

Jun 13, 2014 6:46:29 PM org.eclipse.om2m.comm.http.RestHttpServlet service
3. INFO: HttpRequest
representation=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

4. INFO: ResponseConfirm [statusCode=STATUS_BAD_REQUEST,
representation=<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<om2m:errorInfo xmlns:om2m=""
    <om2m:additionalInfo>Bad TargetID</om2m:additionalInfo>
, resourceURI=null]

Dans INFO 3, le URI est une combinaison de "Base" et " Target ID",
comme le Target ID est "Null", le URI n'est pas pareil avec le contact
dans le item "subscription".

Dans INFO 4,  le server NSCL retourne un résultat "Bad Target ID".

En fait, je ne comprends pas bien l'attribut "Base" /** Request base
uri */ dans le class
RequestIndication( Je n'ai pas
trouvé non plus où cet attribut est donné la valeur dans le class
RestHttpServlet ( paquet: org.eclipse.om2m.comm.http). Est-ce que vous
pouvez m’aider à résoudre ce problème ?

Je vous remercie beaucoup par avance.


LIU Feifei
" Ce courriel et les documents qui lui sont joints peuvent contenir des
informations confidentielles ou ayant un caractè privéS'ils ne vous sont
pas destiné nous vous signalons qu'il est strictement interdit de les
divulguer, de les reproduire ou d'en utiliser de quelque maniè que ce
soit le contenu. Si ce message vous a é transmis par erreur, merci d'en
informer l'expéteur et de supprimer imméatement de votre systè
informatique ce courriel ainsi que tous les documents qui y sont attaché"


" This e-mail and any attached documents may contain confidential or
proprietary information. If you are not the intended recipient, you are
notified that any dissemination, copying of this e-mail and any attachments
thereto or use of their contents by any means whatsoever is strictly
prohibited. If you have received this e-mail in error, please advise the
sender immediately and delete this e-mail and all attached documents
from your computer system."

Back to the top