Re: Subscription functionality

[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

[Ivan Cauchi]

Hi Jacques

I had identified the Content entity for the new
serviceNameOnSubscriptionExpiry as that was the entity used for
serviceName, with the latter currently running once at the activation of
subscription and again for every runSubscriptionAutoReorders.  I was taking
serviceName as being the trigger for external provisioning on activation of
a subscription, but thinking about it more, serviceName is strictly
speaking a generic service to run when the content is consumed, i.e. not
tied to subscription specifically.

So actually serviceNameOnSubscriptionExpiry may be more appropriate in
SubscriptionResource
entity as you suggested.

I also see your point about premature optimisation.  I'm not too committed
one way or another, so happy to take your guidance on taking the road of a
new runServiceOnSubscriptionExpiry service.

Who would open the Jira?  Would that be myself or a committer?

I suppose there would need to be a wider consensus from the broader
community or at least the main committers for this proposed change.

regards
Ivan


On Tue, Sep 24, 2013 at 7:34 PM, Jacques Le Roux <
[hidden email]> wrote:

> 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
>

--
Ivan Cauchi
Director
Falcon ICT Pty Ltd

phone: [phone]

[Jacques Le Roux]

I believe, if people were against the idea they would have already raised hands
You should create the Jira: https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices

Welcome

Jacques

Falcon ICT Pty Ltd wrote:

> Hi Jacques
>
> I had identified the Content entity for the new
> serviceNameOnSubscriptionExpiry as that was the entity used for
> serviceName, with the latter currently running once at the activation of
> subscription and again for every runSubscriptionAutoReorders.  I was taking
> serviceName as being the trigger for external provisioning on activation of
> a subscription, but thinking about it more, serviceName is strictly
> speaking a generic service to run when the content is consumed, i.e. not
> tied to subscription specifically.
>
> So actually serviceNameOnSubscriptionExpiry may be more appropriate in
> SubscriptionResource
> entity as you suggested.
>
> I also see your point about premature optimisation.  I'm not too committed
> one way or another, so happy to take your guidance on taking the road of a
> new runServiceOnSubscriptionExpiry service.
>
> Who would open the Jira?  Would that be myself or a committer?
>
> I suppose there would need to be a wider consensus from the broader
> community or at least the main committers for this proposed change.
>
> regards
> Ivan
>
>
> On Tue, Sep 24, 2013 at 7:34 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> 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

[Ivan Cauchi]

Hi all

JIRA 5333 has been created.

regards
Ivan


On Wed, Sep 25, 2013 at 4:03 PM, Jacques Le Roux <
[hidden email]> wrote:

> I believe, if people were against the idea they would have already raised
> hands
> You should create the Jira:
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
>
> Welcome
>
> Jacques
>
> Falcon ICT Pty Ltd wrote:
> > Hi Jacques
> >
> > I had identified the Content entity for the new
> > serviceNameOnSubscriptionExpiry as that was the entity used for
> > serviceName, with the latter currently running once at the activation of
> > subscription and again for every runSubscriptionAutoReorders.  I was
> taking
> > serviceName as being the trigger for external provisioning on activation
> of
> > a subscription, but thinking about it more, serviceName is strictly
> > speaking a generic service to run when the content is consumed, i.e. not
> > tied to subscription specifically.
> >
> > So actually serviceNameOnSubscriptionExpiry may be more appropriate in
> > SubscriptionResource
> > entity as you suggested.
> >
> > I also see your point about premature optimisation.  I'm not too
> committed
> > one way or another, so happy to take your guidance on taking the road of
> a
> > new runServiceOnSubscriptionExpiry service.
> >
> > Who would open the Jira?  Would that be myself or a committer?
> >
> > I suppose there would need to be a wider consensus from the broader
> > community or at least the main committers for this proposed change.
> >
> > regards
> > Ivan
> >
> >
> > On Tue, Sep 24, 2013 at 7:34 PM, Jacques Le Roux <
> > [hidden email]> wrote:
> >
> >> 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
>

--
Ivan Cauchi
Director
Falcon ICT Pty Ltd

phone: [phone]