Fiware-Service should be Optional

[AnotherCodeArtist]

When using Orion, the use of the firware-service header field is optional. So I'd expect it to be optional here as well, which, however, is not the case yet.
The bigger issue is, that this currently breaks the interaction between several components of the FIWARE-Stack, which is: Sensor -> IDAS -> ORION -> CYGNUS -> DataSink

The problem is, that there's apparently a bug in CYGNUS, that does not send the Fiware-Service header to ORION when registering a subscription. Consequently all subscriptions made this way, end up in ORION's default database ("orion").
On the other hand, IDAS cannot deal with this default tenant/database, since it requires the user to provide a fiware-service header. BTW, this in combination with the 'fiware-servicepath' can lead to really strange situations as you can read here. So the important point is, that no service or sensor can be registered for any entity stored in the default database, wheres CYGNUS currently can register subscriptions ONLY for entities in the default database. Thus, sensor data cannot be stored in Big Data stores!

Apparently the Cygnus team is not very responsive, so maybe the faster workaround is you making this field optional which should be done anyway, since this complies to the specification of NGSIv2.

[dmoranj]

I'm afraid the following assert "CYGNUS currently can register subscriptions ONLY for entities in the default database" is not, by itself, true. I will ask my Cygnus colleagues to extend about that matter in this same thread. I suppose, anyway, that you may be speaking about the global instances of Context Broker and Cygnus, both of them configured without the multiservice flag. In separate installations where you have administration rights, it shouldn't be a problem.

Concerning the Context Broker issue you were referring, the problem there is the support of the wildcard "/*" as the service path value. This feature is not currently supported in the IoTAgents. Even if it was, in fact, I don't think POST information should support that wildcard (you refer to the error when a measure is sent) as the target for newly created data should be clearly identified. This could be useful for GET operations (but it's not currently on the roadmap, I can't give you a date at this time). There is an issue concerning the different use of fiware-service and fiware-servicepath in Orion and the IoTAgents here.

Concerning NGSIv2, we should update the IoTA Library to support it, but our resources are scarce, and that will be a huge feature, so it will take some time for it to arrive to the develop branch.

[dmoranj]

Concerning the following paragraph or the linked issue:

I came across this problem when I was using IDAS. It turned out that a wildcard servicepath ("/*") did not actually work and always produced an error when I tried to add a sensor value. So I had to use the root path initially ("/").

Be aware that "/*" and "/" have very different meanings: the former does not make sense in a device creation or a measure post, where the second one has. The "/" service path is not a wildcard, but a special service path.

[frbattid]

Hi, this is @frb, from the Cygnus team.

The Cygnus issue @AnotherCodeArtist mentions was commented by my side 9 days ago, and fixed 3 days ago. I think we were responsive enough :)

Being said that, the Cygnus API regarding Orion subscriptions is just a beautiful way of centralizing all the steps required for setting up Cygnus. But it is not mandatory, since a subscription request made to Cygnus API it is simply forwarded to Orion API. Thus, the suscription can be directly made using Orion API.

[AnotherCodeArtist]

Hi @frb! Thanks for fixing this issue rather quickly and therefore your responsive ;-)! The whole servicepath thing Imho still suffers from some design flaws (see this thread).

The only thing I suggested for the IoT agent was to make the service-path optional to bring it in line with the context-broker.

[dmoranj]

All the servicepath behavior is implemented in the IoTAgents library, and we have an issue there regarding the differences in behavior between the CB and the IoTAs. I will close this one, as this is not related only to the UL IoTAgent.