Hi, I have one IOT gateway (XDK).

Great. It sounds like you have one of these:

I don't have one, so all my knowledge comes from a quick read of their online documentation, looking for ways that device can communicate with the outside world.

It looks like the normal workflow is to connect your XDK110 Gateway to the XDK Workbench via COM (or JLink for debugging) and then write a short program to collect sensor data and send that data via various protocols to a network destination. Once you've debugged it, you load it into the XDK110, and enjoy the new connectivity.

The documentation tells me the XDK provides several protocols, but the ones that really jump out at me are HTTP and REST. Everything in your ThingWorx Thing model is exposed via REST, so I think writing a program in XDK Workbench that changes property values with a REST call is the easiest way to go.

Like I said, I don't have an XDK110 of my own, so I'll have to speak generally. On my local ThingWorx instance, I have a Thing Model that contains Vehicles. It's easy for me to set the VehicleSpeed property for one of my vehicles, Vehicle41, using a REST call. Here's the code for my REST call:

PUT /Thingworx/Things/Vehicle41/Properties/VehicleSpeed HTTP/1.1
Host: localhost:8080
Accept: application/json
Content-Type: application/json
appKey: aaannnan-nann-nnnn-aaaa-43bd95d50a65
x-thingworx-session: true
Cache-Control: no-cache
Postman-Token: 3f57nnna-nana-nnna-nnna-nnaaaaafd81
{
"VehicleSpeed":66.5
}

Here are the important ThingWorx-specific headers:

• Content-Type: application/json
• appKey: {{an app key generated in your ThingWorx instance}}
• x-thingworx-session: true (lets you authenticate with an appKey, instead of Basic Authentication)

There's a Postman-Token header because I use Postman to test all my REST calls. You don't have to worry about that header.

Here are the steps I'd take to visualize XDK110 data in a ThingWorx mashup:

• In ThingWorx, use Composer to build a Thing Model for the sensors connected to your XDK110. (Here's a page with links to more information on the ThingWorx steps.)
• Using your Thing Model, create a Thing that represents your specific XDK 110.
• Go to Security ... Application Keys in Composer, and generate an app key to authenticate your REST calls.
• Using Bosch XDK Workbench, write a program for your XDK110 to post to your ThingWorx instance. Make the call specific to the Thing and the property you want to update, using the example above. If you need a ThingWorx instance, head over to developer.thingworx.com, where you can get a 30 day hosted instance, or a 120 downloadable instance.
• Once you see the property updating on the Thing view in Composer, build a Mashup to show the data from your Thing in a useful way.

Once you're down the road a bit, and you have a bunch of XDK110s sending data, you may want to explore MQTT. You can write a program in XDK Workbench that posts to an MQTT broker, instead of an HTTP endpoint. There's a free extension in the ThingWorx Marketplace that enables ThingWorx to subscribe to messages on an MQTT broker.

Good luck with the XDK110. It looks like a really nice sensor package.