Post Message to DOE

[Former Member]

Hi to everyone,

I am developing a mobile application for BlackBerry (a custom client), and i am trying to use de API's to connect to the DOE.

I am reading meanwhile this document Integrating Custom Client With DOE.pdf.

Now i am in the post message section, i dont know how to use it.

I can see there is a RFC which recives some paramerts:

-SESSIONID, which i have

-IN_MESSAGE_DETAILS which i dont have.

I dont know what to send to this table. I know that i have to send the message contents so it interact with the DOE. Do anybody know what to send or there is an example to see so i can continue with my custom client?

Hope anybody can help me.

Regards,

Nicolás Eliaschev.

[Former Member · Accepted solution]

Typically, you will be posting several 'messages' in one POST call.

Each 'message' corresponds to a change made to one instance of a data object.

So for each message you need to fill in the following fields:

1. MBO_TRANS - This field should contain a 32 character UUID(or GUID as its called in DOE). It uniquely identifies the data object to which the instance corresponds. Typically, you would have got this UUID by calling 'MSB_GET_LIST_OF_MBO' while before you start creating the custom client (which is described in Section 4.2 of the same document).

2. MSG_ID - This is a 4 byte integer. The first message EVER that a device posts to the DOE will have a value '1'. And this value will keep incrementing by 1 with each message.

The increment spans sessions. This means that each device needs to maintain a running counter of which was the last MSG_ID that it posted in DB/filesystem. Whenever a chunk of messages is posted, the last posted MSG_ID value needs to be updated in the DB to make sure that when you sync again later, you use a new number. Since the integer is 4 bytes, it is safe to assume that you will not run out of MSG_IDs for the entire lifetime of a device.

3. MSG_TYPE - There is only one type of message a device can post, and that is 'T' (which stands for transactional message). Just fill 'T'. (Its explained in Section 7.1 of the document)

Edited by: Arjun Shankar on Dec 1, 2009 5:27 PM

[Former Member · Accepted solution]

continuing..

4. MSG_START_POS - Set this to 0 (assuming that you will not be splitting a message into smaller chunks).

If you ARE using planning to split a message into multiple chunks, this will mean that a single transactional message corresponds to more than one row in the IN_MESSAGE_DETAILS table. In this case, this number should contain the offset for each chunk. My take: Leave this out and set it to 0 for now.

5. TOT_MSG_LENGTH - Each message has an XML document attached to it (see the next field in the table). You need to find the length (number of characters) of the XML document and put it here.

6. MSG_CONTENTS - This field will contain the XML document itself. Section 6 (Message Format) tells you how to form the XML.

7. SENDING_MSG_LEN - If you are not bothered with partial messages, set this to the same value os #5 above (i.e. Length of the XML document)

[Former Member · Accepted solution]

AND dragging some more...

8. SYNC_KEY - Each data object instance is identified in the backend by a set of key fields. The DOE does not want to bother with these key fields (because it is cumbersome and slows down performance). So the DOE assigns each data object instance a UUID (or GUID as its called by the DOE). It's a 32 character field representing the hexadecimal digits for a 16 byte number. If you got an instance originally from the DOE (with GET_MESSAGES) you will already have a SYNC_KEY which you can send for it, stored in the DB. But if the device creates an instance, you need to generate a UUID in the device itself and send it to DOE, and persist it in your DB as well. You can very well use this as the KEY for the table in which you store each NODE.

So here in this field, you put that UUID in 32 character form. It should look like "05D88A43604AF768E10000000A15539D", for example.

By the way: If you intend to create instances or items (child instances) you need to find an API in your blackberry SDK which will generate UUIDs for you.

Thats it!

[Former Member · Accepted solution]

AND I feel like giving a fake example as well!

Lets say, you did 3 changes in the device, you can post them all together to DOE in one POST call. The fields can look like:

<TRANS_FOR_DO_1> - 11 - T - 0 - 520 - <xml_520_characters> - 520 - <SYNC_KEY_UUID_1>
<TRANS_FOR_DO_2> - 12 - T - 0 - 225 - <xml_225_characters> - 225 - <SYNC_KEY_UUID_2>
<TRANS_FOR_DO_1> - 13 - T - 0 - 1120 - <xml_1120_characters> - 1120 - <SYNC_KEY_UUID_1>

As you can see, MSG_ID 11 and 13 are two different changes done to the same instance (and hence the same synckey). You have to make sure that the changes are posted IN THE SAME ORDER as they were done. You can also internally ADD the two changes and post a single message for each instance. Its your call.

Edited by: Arjun Shankar on Dec 1, 2009 5:29 PM

[Former Member · Accepted solution]

Hi Arjun!

Thanks for all you explanation! It is very helpfull

I have one more question, i am using a service in the SICF, then i call to the RFC to post the message.

When I send to MMW_POST_MESSAGES the XML (in MSG_CONTENTS) should i send the hole XML in the Query String when i test the service?

Or there is another way to send the xml?

Thanks a lot you have been so helpfull to me!

Regards,

Nicolás Eliaschev.

[Former Member · Accepted solution]

About the SICF query you had, I did not understand the question. I don't know much about SICF anyway. Maybe if you elaborate in a new question it will catch someone's eye!

[Former Member · Accepted solution]

Hi,

The XML should be in the HTTP request body.

You can read this blog about REST Web Services, the concepts are similar : /people/werner.steyn/blog/2009/11/30/put-soap-to-rest-using-ce

Regards,

Pierre

[Former Member · Accepted solution]

Hi Pierre and Arjun,

I will try to explain better what i want to do.

When I use a service created on SICF, I can call differents API's (LOGIN, POST MESSAGE; GET MESSAGE...) to do the login there is no problem.

But when I try to post a message i have to send the XML, i consume the service via http. This could be an example:

http://sensesrv.sensebyte.com:50400/sap/bc/icf/zmi_serv_test?sap-client=001&DEVICE_ID=001EC9EAB6E902...

I make a zmi_serv_test (service) and I send a DEVICE_ID as a query string. This service return to me a Session ID.

So if i have to do the same thing but to post a message, should i send the XML into the query string?

I saw the Blog you sent to me Pierre but i think this is not what i need.

Hope this time you can understand me

My english isn't the best

Regards,

Nicolás Eliaschev.

[Former Member · Accepted solution]

Hi,

As I said in my previous post, you should use the request body to send the XML.

You should read the blog carefully. Search for word "POSTER" (it's a Firefox plugin) and you'll find the interesting part. In one of the screenshots, you'll see that XML is sent as content (type application/xml). You should do the same for your mobile application.

EDIT : you'll probably have to use the HttpConnection interface to send a POST request : http://www.blackberry.com/developers/docs/4.6.0api/javax/microedition/io/HttpConnection.html

You should read the following thread, it contains some very useful information : http://supportforums.blackberry.com/t5/Java-Development/Connecting-your-BlackBerry-http-and-socket-c...

Regards,

Pierre

[Former Member · Accepted solution]

Hi again Pierre,

I read this Blog and the POSTER, i think i understand now, but i have one last question.

When i post the xml to the service, in the method IF_HTTP_EXTENSION~HANDLE_REQUEST, when i want to receive the XML, should i do a server->request->get_form_field( 'XML' )

Do you understand? If i do the post with the httpconnection in BlackBerry in the method's service should I do the request with a server->request->get_form_field?

Thanks for everything you both have been so helpfull with me

Regards,

Nicolas Eliaschev

[Former Member · Accepted solution]

Hi,

You'll have to find a way to send the XML as application/xml or text/xml content for instance. Then you'll have to [access the HTTP body data|http://help.sap.com/saphelp_nw04/helpdata/en/78/98528ac06b11d4ad310000e83539c3/frameset.htm] and parse the XML.

Regards,

Pierre

[Former Member · Accepted solution]

Hi,

The basic methods follows..

server->request->get_cdata( ) will give you the whole http request body .

server->request->get_header_field('HEADERNAME') will give you the header data

server->response->set_data( data = binarystring) will set the response for an http request

and the above is accessible in the method IF_HTTP_EXTENSION~HANDLE_REQUEST of the class implementing the interface IF_HTTP_EXTENSION

Liji

[Former Member]

In the XML that i sen to the DOE.

In section 6, it shows to me the message format. I can see there is a STATE_ID, where is that where should i look for it?

Thanks a lot again

Regards

Nicolás Eliaschev

Edited by: Nicolas Eliaschev on Dec 1, 2009 10:08 PM

[Former Member]

You're welcome!

I am not very sure about STATE_ID behavior but here is how I think it works:

STATE_ID is another UUID. The DOE changes the STATE_ID of a row each time it is updated by someone (either backend or a device). It uses this to resolve conflicts (when conflict resoultion is turned on).

What I mean is this:

Say, the backend updates an instance of a DO. The DOE assigns a STATE_ID, lets say 'UUID_A', to it. This flows down to the device (so it is part of the XML you get in GET_MESSAGES). Now, say, the backend updates the instance again. So the DOE updates the STATE_ID for that instance to a new value 'UUID_B'. Lets now assume that this change is not sent to the device yet. Now, the device also changes the instance (but the device is working on an older version of the instance (STATE_ID is still 'UUID_A' in the device). When the device syncs later on, the message sent by the device is rejected (because the device claims to be working on the UUID_A version of the instance whereas the DOE has a newer version of the instance 'UUID_B').

On the other hand, if the backend had never updated the instance in the first place, the row would still have UUID_A assigned to it in the DOE as well as device. Now if the device sends an update to the instance, DOE will accept it (since it knows that the device has been working with the latest data, since the STATE_ID matches its own copy).

=> Device need not bother about STATE_ID. Treat it like just another field and keep sending whatever value you get from the DOE back to it whenever send an update to it. Don't change it on the device. Moreover, if the DOE accepts an update (with a 'Confirmation' message), it will also send you the new STATE_ID. You need to persist this new value.

[Former Member]

Hi,

Arjun > thanks for the details!

Do you know if a standard mobile application uses the same APIs? It would be great if we could debug these FM to see what's going on with a standard application. By the way, which user is used to execute these FM? Is it a technical user?

Regards,

Pierre

[Former Member]

The Client Framework shipped by SAP communicates via HTTP. These RFC APIs like, in this case, MMW_POST_MESSAGES are obviously wrappers around the DOE's internal code (otherwise they wouldn't work). So yes, at one point the code traversed during a call to the RFC API is the same as that which will be traversed when you sync using the SAP shipped client framework.

Anyway, you're free to dive into the code written inside these RFC in your DOE system. It won't be hard to find the common factor.

[Former Member]

I do not know what a 'technical user' means. Ideally, the device should ask the user for a synchronizing user/password and use this to set up the RFC connection. All the RFC calls should then be made with the user/password provided by the user.

The DOE verifies if the user which is being used to synchronize (essentially to LOG INTO the DOE system with a valid R/3 user/password) has in fact been assigned to the device which is synchronizing. If not, then it rejects all the messages that have been posted.

[Former Member]

>

> I do not know what a 'technical user' means. Ideally, the device should ask the user for a synchronizing user/password and use this to set up the RFC connection. All the RFC calls should then be made with the user/password provided by the user.
> 
> The DOE verifies if the user which is being used to synchronize (essentially to LOG INTO the DOE system with a valid R/3 user/password) has in fact been assigned to the device which is synchronizing. If not, then it rejects all the messages that have been posted.

I meant "system" user. Thanks.

Regards,

Pierre

[Former Member]

Hi,

This table is of type SMMW_MSG_DETAILS. This type is described in section 5.7.1 in the document you mentioned.

Regards,

Pierre