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 < [email protected]> 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: +61 414208449
