Hi all JIRA 5333 has been created.
regards Ivan On Wed, Sep 25, 2013 at 4:03 PM, Jacques Le Roux < [email protected]> 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 < > > [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
