DevLost

Some time ago I posted this question on Stackoverflow:

how to make the multitenant option of Orion context Broker working with Cygnus connector?

Since I was not receiving any answer and I was getting impatient :-) I squezeed my brain to look for a solution on my own and when I found out the solution I answered to the question on Stackoverflow.

All done? Yes, but I think it's worthwhile to add more pieces of the puzzle and share more of our experience with FIWARE GEs.

The fact is that, for our Smart Attention Project, we need to save historical data whereas Orion Context Broker keeps just the last data received. One of the suggested methods is to persist data into a mySql instance using the Cygnus connector bundled with Orion.

As we have to manage several mesh networks (from 1 to 10 or even more) that use the same entities/attributes/subscriptions definitions we wanted to leverage the multitenant option of Orion Context Broker in order separate data coming from different networks. According to the user and programmers guide of Orion, a specific HTTP header "Fiware-Service" should be added to each HTTP Request coming from the gateways of the mesh networks in order to persist data into different databases.

Furthermore, if you want to store the information for each entity in a different table, you need an additional header: "'Fiware-ServicePath".

In brief, if you want different DBs for different scenarios and different tables for different NGSI entities you should add these headers:

'Fiware-Service: DB_name'

'Fiware-ServicePath: table_prefix'

then, you should obtain:

dbName=DB_name
tableName=table_prefix_<entityId>_<entityType>

But, if you do so, probably you won't be able to get it work. Why? Just because Orion documentation does not clarify that you have to include these headers in all the NGSI REST call to Orion Context Broker, not just once or just for the registration of an entity.

If you already have your entities registered, simply delete them (delete also the subscriptions) and follow these steps to make things work:

1) Register your entity with a POST /NGSI10/updateContext call specifying "APPEND" updateAction in payload and including "fiware-service" and "fiware-servicepath" headers.

2) Make a subscription (/ngsi10/subscribeContext) to Orion including exactly the same headers above

3) Update your entity including always the headers above

We are playing with this GE from a while and we found that there is not a quick way to delete/modify a single event sink.

What to do then?

We found two ways, but both require additional operations:

1) reset the full chain of CEP app with "/admin/espr4fastdata" REST call, but this requires to registrate again all the event types, statements etc.

2) delete the related statement, recreate it and recreate the event sink

I was testing the subscription/notification feature of Orion Context Broker (https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index...)  and I made a number of subscriptions without taking note of the ID of the new subscription returned by the system.

Soon I went in a situation where Orion was firing a lot of notifications  to the Cygnus connector that I had configured.

I wanted to delete most of the subscriptions, but the REST call available, i.e. unsubscribeContext, requires that you know the id of the subscription. What to do then?

Official documentation suggests, as ultimate remedy, to delete the entire database: (https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Publish/Subscribe_Broker...).

But I was reluctant to follow this way and then I looked for a mongodb admnistration and found this umongo:

http://edgytech.com/umongo/

The installation is trivial: just download the zip file, unzip and launch launch-umongo.sh

I loaded the default instance of mongodb in my linux box and started to look for an id under orion databases; the subscriptions are in the csubs collection:

Then I created a simple REST call in SoapUI to unsubscribe the subscription with that ID:

Orion Context Broker is an open source component belonging to the wide archipelago of FIWARE components available on this site.

In particular, if you are developing a Data/Context scenario, the Orion Context Broker plays the role of a component in the architecture able to mediate between consumer producers (e.g. sensors) and the context consumer applications (e.g. an smartphone applications taking advantage of the context information provided by the sensors). It runs as a deamon process providing NGSI9 and NGSI10 interfaces. Full documentation here.

When I started to work with Orion Context Broker for my SAT project, I looked around to find a quick & stylish solution to display data stored in the DB used by Orion CB (btw mongoDB); soon I found Freeboard, a nice open source dashboard for the Internet of Things and a "ready to work" plugin for Freeboard that is able to connect it to an Orion instance: Freeboard-Orion-Plugin.

All right? All OK? No, unfortunately the plugin did not work in all my attempts . The fact is that, behind the scene, the freeboard plugin makes a cross-domain Ajax call to my Orion instance and this is inhibited by design due to browser-enforced, same-origin security policies for JavaScript.

What to do then ? Recently W3C came out with the Cross Origin Resource Sharing (CORS) specification, a mechanism that works by adding HTTP headers to cross-domain HTTP requests and responses. The headers indicate the origin of the request and the server has to inform via headers in the response whether it will serve resources to this origin.  This exchange of headers is what makes CORS a secure mechanism totaly transparent to the user since the headers are built by the browser and the server.

So, why it did not worked in my case?

Just because Orion context Broker server does not support CORS at the moment:

http://stackoverflow.com/questions/28246116/no-access-control-allow-origin-header-is-present-on-orion-context-broker

https://github.com/telefonicaid/fiware-orion/issues/501

there is more than a solution to get rid of the problem. You may create for instance a proxy in PHP:

https://github.com/inter-coder/Orion-Web-Proxy-for-Cross-Domain

My Solution:

I followed a different way; I installed Apache httpd on the same machine of the Orion instance and I used it as a proxy.

To do so just follow the steps below:

1) Edit httpd.conf file in /etc/httpd/conf and instruct Apache to load proxy module add the following lines at the end:

LoadModule  proxy_module         modules/mod_proxy.so
LoadModule  proxy_http_module    modules/mod_proxy_http.so
LoadModule  headers_module       modules/mod_headers.so
LoadModule  deflate_module       modules/mod_deflate.so

2) Add proxy permissions as your choice:

<Proxy *>
   Order deny,allow
Allow from all
</proxy>

3) Add some rules to instruct Apache to intercept NGSI calls to Orion:

ProxyPass /v1/queryContext http://127.0.0.1:1026/v1/queryContext
ProxyPassReverse /v1/querycontext http://127.0.0.1:1026/v1/queryContext
ProxyPass /v1/registerContext http://127.0.0.1:1026/v1/registerContext
ProxyPassReverse /v1/registerContext http://127.0.0.1:1026/v1/registerContext
ProxyPass /v1/updateContext http://127.0.0.1:1026/v1/updateContext
ProxyPassReverse /v1/updateContext http://127.0.0.1:1026/v1/updateContext

4) Save conf file and restart your httpd server