Does the Task Gateway service support subscriptions ? it's confusing to say the least

[Former Member]

Try this :

(1) access the root service of an activated Task Gateway service on SAP NW Gateway (mine is SP09 and I am using version 2 of the Task Gateway service) - that should be a URL like : https://<myserver>.<mydomain>/sap/opu/odata/IWPGW/TASKPROCESSING;mo;v=2/

You will see a SubscriptionCollection and a NotificationCollection and the TaskCollection has an indicator saying it is subscribeable

(2) In SE24 locate the data provider class for the task gateway service (/IWPGW/CL_TGW_EDP_TASK_V2) and look at its inheritance tree

/IWPGW/CL_TGW_EDP_TASK_V2 inherits from /IWPGW/CL_TGW_EDP_TASK, which inherits from - surprise surprise - /IWBEP/CL_MGW_ABS_DATA

That's rather awkward cause - as the root service tells you the service supports subscriptions - one would normally expect to find an inheritance tree climbing up to the base class /IWBEP/CL_MGW_PUSH_ABS_DATA, as all other services do when they support subscriptions.

Not so with the Task Gateway service

(3) Use a REST client to try and create a subscription for the TaskCollection in the Task Gateway service

Result : KO, It doesn't work (at least not for my setup)

To summarize

=> OBSERVATIONS
(1) the root service tells you, you can subscribe to the TaskCollection in the Task Gateway service

(2) the provider class however doesn't appear to have the right inheritance to do so

(3) when trying to create a subscription, things blow up in your face (as you would expect considering (2), but not in an honest way cause (1) promises you, it can

=> QUESTIONS

(1) How to explain the availability of the SubscriptionCollection / NotificationCollection in the root service ?

(1) Are subscriptions supported or not - because of some technical limitation

(3) If one would like to subscribe to the TaskCollection in the Task Gateway, would it be possible to enable this by changing the inheritance tree ?

(2) If it can work, how does the subscription process work considering Task Gateway service is a moc (multiple origin composition) service - assuming that during the creation of a subscription, the gateway - according to SAP help - contacts the backend system to validate (authorize ?) the request.

[Former Member · Accepted solution]

After a closer look, it turns out that the explanation for the appearance of the subscription/notification collection is by itself simple :

It comes from the fact that the model class implemented by the data provider does inherit from the push enabled base class : /IWBEP/CL_MGW_PUSH_ABS_MODEL

The model controls the number of collections listed in the root of the service, not the data provider class (which in the end appears logical).

Still it leaves the question :

Why did SAP use a push enabled model class and then decided to inherit the provider class from a based class that doesn't support it.

This could mean 2 things :

(1) Either they ran into undocumented technical issues with it and eventually decided not to implement it; By changing the base class to the one without push support, SAP may try to keep customers from creating subscriptions for the Task Gateway collections.

(2) There exists no such problem and it is just an oversight from SAP's developers and enabling push could simply be done by changing the inheritance to the push enabled provider base class

Which one is it going to be ?

[Andre_Fischer · Accepted solution]

Hi Theo,

the Task processing service does not support subscription / notification. The reason that the metadata of the service does contain information about Subscription / Notification is only a legacy.

The task processing service ist only a „pull“ service that ready data from task provider (backend) systems that are configured by the customer.

For a notification based approach these task provider systems would have to offer support for notification which is not the case.

Best Regards,

Andre

[Former Member · Accepted solution]

Hello Andre,

Thanks for your reply.

I have doubts though about your statement that "for a notification based approach these task provider systems would have to offer support for notification which is not the case",

As far as I know, in order to send notifications, there will always be a need to write custom code in the backend (provider) system. It's not something that you would expect to just be there or to be an integral part of the service/provider implementation as such.

From the SAP documentation, I conclude that enabling a service for subscription is basically a matter of inheriting from the push enabled data provider base class. Once you do that you have enabled the storage of subscriptions for the collections in that service (provided they are enabled for subscription). The implementation of the subscription / notification collections for a service is implemented in that base class, it's not something  you have to implement for each service. So, as far as the creation and storage of subscription items is concerned, there appears to be no special effort required. Mind however : this just covers the subscriptions creation and storage.

When and how notifications are submitted to their delivery points is something that in my opinion will always require custom coding in the backend, but it is orthogonal to how the pull side of a service is implemented.

Typically you would write handlers for specific events in the backend and make the emission of notifications an integral part of the backend handling of those events.So, in your typical coding you would use the available IW_BEP API to check for subscriptions for a particular collection, generate the notification endpoints and then submit them via the SAP NW Gateway to their respective consumers. The connection between backend and gateway uses bgRFC to ensure delivery. The gateway processes the inbound queue of incoming notifications and submits them to their final destination. Consumers in this context are the communication providers that are referenced in the subscriptions (through the delivery address).

[Andre_Fischer · Accepted solution]

Hi Theo,

in principal you are right and it works as you have described it.

However only the task processing service is IW_BEP based which calls the task provider implementations which are not based on IW_BEP.

Therefore the notification part is not applicable in this special case.

Best Regards,

Andre

[Former Member · Accepted solution]

Thanks Andre for the clarification.

Does this mean that the creation of a subscription fails - even if one would change the inheritance of the data provider class to the one that supports subscriptions - because of the fact that the create subscription method at some point in its processing of a request will try to find a system alias (as the source system) for that subscription, but that this will fail for the TASKPROCESSING service due to the fact that all system aliases defined for that service are system aliases specifically for the provider implementations and not for the task gateway service itself ?

[juergen_kremer · Accepted solution]

Hi Theo,

the TASKPROCESSING service “delegates” the call towards task providers, so if one would change the inheritance of the data provider class to the one that supports subscriptions the task providers would need to deal with subscription. What would need to be supported is defined in the abstract class which is implemented by the task providers and not all task providers do support each capability foreseen. So subscription might fail for a particular task provider. Thus proper notification handling would need to be defined from the task provider to consumer, which as well is not the case as of today.

Thanks and best regards,

Juergen

[Former Member · Accepted solution]

Hi Juergen,

Thanks for your additional comments.

So, no subscriptions/notifications support then for the task gateway. Too bad, so we will have to figure out how to solve our issue a different way.

Thanks all for your feedback. Closing the discussion.

[paul_abrahamson_sap · Accepted solution]

It is a shame, the we'd need to implement these kinds of scenarios in another way. It should be possible for business critical tasks to be able to have push notifications to send out to mobile devices via HCPms for example. There'll certainly be ways to achieve this but would mean custom development.

Andre / Juergen

Has SAP got any plans to provide an ability to subscribe to push notifications for the My Inbox / Task Gateway service in future?

Theo it'll be interesting to see how you have solved this in your use case.