[
https://issues.apache.org/jira/browse/OFBIZ-5333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13975481#comment-13975481
]
Ivan Cauchi commented on OFBIZ-5333:
------------------------------------
Hi all
apologies for the lengthy silence.
Please find attached the patch which introduces the functionality described
previously, implemented in the service runServiceOnSubscriptionExpiry. This
can be run manually, and is also being scheduled in the demo data to run daily
at midnight.
There is some demo data which has been added to the GZ-NEWS
SubscriptionResource, the GZ-NEWS-1MO ProductSubscriptionResource as well as a
dummy service runSubscriptionExpired which has been inserted into the column
SubscriptionResouce.serviceNameOnExpiry.
Currently Subscription.automaticExtend=N and
Subscription.automaticExtend=(null) are treated the same.
The process for testing the new functionality is:
1) create sales order 'testsubscriptionorder', democustomer, demo catalog,
select GZ-NEWS-1MO product. Order WSCO10000. quick finalise order, no
shipping, create order, Approve order
2) Go to catalog->subscription->Find subscription. Click on subscriptionId
(10000). Update fromDate and thruDate to a date in the past. Like
fromDate(2013-11-01 ) and thruDate (2013-11-02). Update "Use Time Uom" to "time
in days" and "automatic extend" to "N" and Grace Period on Expiry to "1" and
Grace Period UOM Time to "time in days". Update
3) run service runServiceOnSubscriptionExpiry manually, or wait for it to run
at midnight. In the log file, look out for entries similar to the following:
[java] 2014-04-20 10:04:19,684 (http-bio-0.0.0.0-8443-exec-6)
[SubscriptionServices.java:364:INFO ] Subscription expired successfully for
subscription ID:10000
[java] 2014-04-20 10:04:19,690 (http-bio-0.0.0.0-8443-exec-6)
[SubscriptionServices.java:371:INFO ] Service mentioned in serviceNameOnExpiry
called with result: runSubscriptionExpired service called successfully with
subscriptionId 10000
Both entries in the log file are generated by the master
runServiceOnSubscriptionExpiry process, however part of the second entry (after
'... called with result:' is generated by the dummy service, which is expected
to change depending upon the specific service logic that providers will write.
runServiceOnSubscriptionExpiry has been implemented as discussed in the
developer forum, with the service mentioned in Content.serviceName being called
for eligible subscriptions every time runServiceOnSubscriptionExpiry is run.
If the subscription record is still there the next day, Content.serviceName is
run again. To our mind this can result in a scalability issue. We're open to
discussing the logic of this.
We invite any committer to test and commit to trunk if the functionality is
deemed useful.
We are delighted to be contributing to the OFBiz community.
> Trigger for service to run upon subscription expiry
> ---------------------------------------------------
>
> Key: OFBIZ-5333
> URL: https://issues.apache.org/jira/browse/OFBIZ-5333
> Project: OFBiz
> Issue Type: Improvement
> Components: content, order, product
> Affects Versions: SVN trunk
> Reporter: Ivan Cauchi
> Labels: entity, expiry, patch, product, service, subscription
> Fix For: SVN trunk
>
> Attachments: CR_0003_V05.updated.patch
>
>
> This issue is a follow up of a discussion on the Ofbiz user and dev fora,
> titled 'Subscription Functionality'.
> The main characteristics of the Ofbiz subscriptions are:
> a) 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 Content.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 Content.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 SubscriptionResource entity, called
> serviceNameOnExpiry (note to people that had followed the discussion on the
> Ofbiz mailing lists: the field name has been shortened to fit the 30
> character limit). This would contain the service to run to trigger the
> deprovisioning process. If containing null, nothing would be run, and Ofbiz
> exhibits the current default behaviour.
> b) create a new service runServiceOnSubscriptionExpiry within
> SubscriptionServices.java, that is scheduled to run regularly, similar to the
> existing runSubscriptionAutoReorder. This code would check whether a
> subscription has expired. If so, and a service exists within
> SubscriptionResource.serviceNameOnExpiry, and Subscription.automaticExtend=N,
> this code runs that service.
> This approach has the advantage of complete separation of the default and new
> functionality with the cost of some additional database lookups.
> We will be submitting patches for this new functionality shortly.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
