Subscription functionality

[Ivan Cauchi]

Hi all

I have been thinking of this subject for a while.  The main characteristics
of the Ofbiz subscriptions are:
a) as noted in the Amicontech link, the access control of the subscribed
internal content is missing, and can be provided by custom means. As well,
subscription to content on external systems needs a trigger, which can be
provided through serviceName.
b) the subscription model has an inbuilt assumption that access to the
resource is terminated outside of the default Ofbiz, such as by a custom
Ofbiz process or an external process.

The generic use case I'm thinking of is external systems providing content
to which a client desires to subscribe which don't have an inbuilt expiry.
 These systems require a trigger to enable provisioning, and another
trigger to enable deprovisioning.

Ofbiz can be used to manage the provision of access to such external
content, triggering the provisioning process through a service in
serviceName.  What's missing is an (optional) trigger for the
deprovisioning process.

One way which we're thinking of resolving this is:
a) to add another column to the Content entity, called
serviceNameOnSubscriptionExpiry.  This would contain the service to run to
trigger the deprovisioning process.  If containing null, nothing would be
run, and the Ofbiz exhibits the current default behaviour.
b) add some code to an existing Ofbiz service, or create a new one, that is
scheduled to run regularly.  This code would check whether a subscription
has expired.  If so, and a service exists within serviceNameOnExpiry, and *
Subscription.automaticExtend=N,* this code runs that service.  This code
can be added as a modification to runSubscriptionAutoReorder in
OrderServices.java,  or as a new process runServiceOnSubscriptionExpiry
within SubscriptionServices.java.  The former has the advantage that lookup
of subscription entities is done once, both for extension and expiry, with
the disadvantage of the code may be seen as beyond scope of the existing
service.  The latter has the advantage of complete separation of the
default and new functionality with the cost of more database lookups.

If there is any interest in the Ofbiz community, I'd be prepared to offer
this code for inclusion in the Ofbiz trunk.  I'm also open to any
suggestions or discussion.

regards


--
Ivan Cauchi
Director
Falcon ICT Pty Ltd

[Jacques Le Roux]

It's an interesting propostion. Though I wonde why putting the field serviceNameOnSubscriptionExpiry in Content rather than in SubscriptionResource entity? (to keep the data model easier to understand)

I'd prefer a new runServiceOnSubscriptionExpiry service, I'm against premature optimisation.
In case of performance issue, you can always refactor the code after respecting higher level of abstractions (here as you said "complete separation of the default and new functionality")

We should continue to discuss this on the dev ML (I copy there also)
If we agree, the way should be to open a Jira and submit a patch

Thanks

Jacques

Falcon ICT Pty Ltd wrote:

> Hi all
>
> I have been thinking of this subject for a while.  The main characteristics
> of the Ofbiz subscriptions are:
> a) as noted in the Amicontech link, the access control of the subscribed
> internal content is missing, and can be provided by custom means. As well,
> subscription to content on external systems needs a trigger, which can be
> provided through serviceName.
> b) the subscription model has an inbuilt assumption that access to the
> resource is terminated outside of the default Ofbiz, such as by a custom
> Ofbiz process or an external process.
>
> The generic use case I'm thinking of is external systems providing content
> to which a client desires to subscribe which don't have an inbuilt expiry.
> These systems require a trigger to enable provisioning, and another
> trigger to enable deprovisioning.
>
> Ofbiz can be used to manage the provision of access to such external
> content, triggering the provisioning process through a service in
> serviceName.  What's missing is an (optional) trigger for the
> deprovisioning process.
>
> One way which we're thinking of resolving this is:
> a) to add another column to the Content entity, called
> serviceNameOnSubscriptionExpiry.  This would contain the service to run to
> trigger the deprovisioning process.  If containing null, nothing would be
> run, and the Ofbiz exhibits the current default behaviour.
> b) add some code to an existing Ofbiz service, or create a new one, that is
> scheduled to run regularly.  This code would check whether a subscription
> has expired.  If so, and a service exists within serviceNameOnExpiry, and *
> Subscription.automaticExtend=N,* this code runs that service.  This code
> can be added as a modification to runSubscriptionAutoReorder in
> OrderServices.java,  or as a new process runServiceOnSubscriptionExpiry
> within SubscriptionServices.java.  The former has the advantage that lookup
> of subscription entities is done once, both for extension and expiry, with
> the disadvantage of the code may be seen as beyond scope of the existing
> service.  The latter has the advantage of complete separation of the
> default and new functionality with the cost of more database lookups.
>
> If there is any interest in the Ofbiz community, I'd be prepared to offer
> this code for inclusion in the Ofbiz trunk.  I'm also open to any
> suggestions or discussion.
>
> regards