Marc, Yes, #1 is probably the better option, with the limit on number of users on the ProductSubscriptionResource.
BTW, are you looking for where to put the number of users, or the number of times it can be used? You could use the "useCountLimit" field for either, but it was really meant as a limit for the number of times a subscription resource can be used. Taking a quick look at the entities there is no field for limiting the number of users, but you could certainly ad that easily to ProductSubscriptionResource and Subscription. -David On Oct 29, 2009, at 9:31 AM, Marc Morin wrote: > We sell a number of DIGITAL_GOOD subscriptions for our services: > > AIS-1 1 user monthly subscription to the platform > AIS-10 10 user "" > EMAIL-1 1 user email account > EMAIL-10 10 "" > > etc... > > This manages Subscriptions for the Party for each customer and re-generates a > new Order every month and that's all great. > > We have a service that we associate with the ProductContent with > FULFILLMENT_EXTSYNC productContentTypeId to do the actual provisioning. We > track our uses by extending the SubscriptionActivity and associating it with > the Subscription via the SubscriptionFulfillmentPiece. > > My question is how best to model the useCountLimit for the various products. > Seems like creating a virtual product for the base product and then either > > 1) create a variant for each consumption package, associate a different > ProductContent with the variant setting the useCountLimit appropriately then > in my service, can enforce that limit in the Subscription table. > 2) create variant and put the limit in a product attribute and manage use > count there > > Seems like #1 is a more desirable approach? > > There doesn't appear to be any code that uses the useCountLimit anywhere. > So, it would appear like adding an eeca on SubscriptionFulfillmentPiece that > will limit the number of SubscriptionActivity records to a specific > Subscription to the useCountLimit (if not null), seems like the right way to > go? > > Marc >
