Hi Ivan, Thank you of describing the issue and a possible solution accompanied by test cases.
Any improvement to the code base is a good idea. And if you'll submit a patch in JIRA I will do my best to review it. Best regards, Pierre Smits *ORRTIZ.COM <http://www.orrtiz.com>* Services & Solutions for Cloud- Based Manufacturing, Professional Services and Retail & Trade http://www.orrtiz.com On Wed, Oct 1, 2014 at 1:59 PM, Falcon ICT Pty Ltd <falcon...@gmail.com> wrote: > Background > ---------------- > Recenlty, the trunk version of OFBiz was augmented with a new service > called runServiceUponSubscriptionExpiry through JIRA5333. This service > is scheduled to run, using the demo data, once a day. Its algorithm > looks up all subscriptions which have expired, which is defined as the > current time being greater than the sum of the subscription.thruDate + > subscription.gracePeriodOnExpiry, and Subscription.automaticExtend is > false. For all such subscriptions, the service runs any service named > in SubscriptionResource.serviceNameOnExpiry. > > > This provides users of the OFBiz framework who provide subscriptions > to their customers using the framework, to trigger an external > deprovisioning action when a subscription expires, implemented as a > service whose name is inserted into > SubscriptionResource.serviceNameOnExpiry. > > > Currently, the service mentioned in > SubscriptionResource.serviceNameOnExpiry is run every time the master > service runServiceUponSubscriptionExpiry goes through its algorithm > (once a day in the demo data). Typically, for subscriptions which > require a deprovisioning action when the subscription expired, one and > only one deprovisioning action would be required. > > > proposed solution > ------------------------ > To resolve this, it is being proposed to make the following adjustments: > > a) augment the OFBiz data model with the following new field: > > Subscription.serviceNameOnExpiryRunDate > > b) modify the algorithm of runServiceUponSubscriptionExpiry to also > check whether the expiry service has already run, by checking that > serviceNameOnExpiryRunDate is null. > > - if serviceNameOnExpiryRunDate is null (and the other conditions are > satisfied), run the service in > SubscriptionResource.serviceNameOnExpiry and update the date/time into > serviceNameOnExpiryRunDate > > - if serviceNameOnExpiryRunDate is not null, skip the expired > subscription and move to the next > > > Testing > ---------- > - create a new subscription through OFBiz with demo data > - modify the subscription's thru date and gracePeriodOnExpiry so the > result of their addition is in the past of the system date > - verify that Subscription. serviceNameOnExpiryRunDate is empty > - either wait for the daily running of > runServiceUponSubscriptionExpiry, or trigger the service manually > - verify that the log file contains a reference to the subscription > having expired, and that Subscription. serviceNameOnExpiryRunDate > contains the date/time the service was run > - either wait for the daily running of > runServiceUponSubscriptionExpiry, or trigger the service manually, for > a second time > - verify that the log file does not contain a reference to the > subscription having expired, and that Subscription. > serviceNameOnExpiryRunDate still contains the date/time the service > was run. > > > I'd like to ask: > a) is there agreement in the developer community that this is a good idea > b) We propose to develop the patch and release it to the OFBiz > project. Would any committer be interested in promoting into trunk > when we provide the patch? > > regards > -- > Ivan Cauchi > Director > Falcon ICT Pty Ltd >
