Access to add and change pages is restricted. See: https://cwiki.apache.org/confluence/display/OFBIZ/Wiki+access

This was extracted from the user mailing list

Subscription: keeps track of entitlement to SubscriptionResource for a certain period of time (ie history of what was purchased/etc, used to check permission to access, etc)
SubscriptionResource: you would have one of these records for each resource, such as a file or a set of files, or a publication, or whatever
ProductSubscriptionResource: this is where you specify how much time and to what resources the customer is entitled to when they purchase the Product; the system automatically creates a Subscription record for each of these when the Product is purchased
If you want a customer to pay for a long period up front, you would just configure a Product for that. If you want the customer to pay monthly, but sign up for a longer period of time (like a year) then you would have a Product setup for 1 month of access, and create a ShoppingList for a recurring Order to happen once a month for 12 months.

-David

Another source with more details

An interesting article about subscription.
To be safe, I also took an HTML copy and attached it localy: amicontech.com subscription article Posted on January 19, 2011 by Sumit Porwal.html

Extension in Subscriptions functionality to trigger activity on external system upon Subscription Expiry - by Ivan Cauchi

This issue is a follow up of a discussion on the Ofbiz user and dev fora, titled 'Subscription Functionality', and the excellent Amicontech article (above):


The main characteristics of the Ofbiz subscriptions are:

  1. 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.
  2. 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.

There is a generic use case with 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 was missing was an (optional) trigger for the deprovisioning process.

This was resolved through JIRA OFBIZ-5333 and available in trunk as from r1597235, as follows:

  1. another column was added to the SubscriptionResource entity, called serviceNameOnExpiry. This contains the service to run to trigger the deprovisioning process. If containing null, nothing would be run, and Ofbiz exhibits the previous default behaviour.
  2. a new service was created, called runServiceOnSubscriptionExpiry within SubscriptionServices.java, that is scheduled to run regularly, similar to the existing runSubscriptionAutoReorder. This code checks 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.

The following fields were also added:

  • ProductSubscriptionResource.gracePeriodOnExpiry
  • ProductSubscriptionResource.gracePeriodOnExpiryUomId
  • Subscription.gracePeriodOnExpiry
  • Subscription.gracePeriodOnExpiryUomId

This will allow the runServiceOnSubscriptionExpiry to trigger the service in SubscriptionResource.serviceNameOnExpiry only after

nowTimeStamp >= Subscription.thruDate + Subscription.gracePeriodOnExpiry.

This provides flexibility in managing the triggering of the deprovisioning service, similar to the flexibility in automatic subscription extensions enabled by Subscription.canclAutmExtTime for runSubscriptionAutoReorders.

The service runServiceOnSubscriptionExpiry 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 have proposed a patch to resolve this which is awaiting review and commit (see JIRA OFBIZ-5793).

  • No labels

2 Comments

  1. Unknown User (richard@mypack.co.uk)

    hi

    could anyone advise on creating a non ending monthly subscription ie with no end date or annual subscription with no end date

    I need to pass data to ofbiz that sets up these types of transactions

    1. Jacques Le Roux

      Ask rather questions on user ML: wider audience, more chances to get (an) answer(s)