|
|
|
|
Using PA, the provider can define configurations of application features, which will be available to customers. This is done by setting up several parameters in the application:
After definition of component parameters, provider may combine application components in multiple offers with different prices for different application features.
Considering example with the mail application discussed above, the provider may sell a single APS application as two offers: simple email and business email. Simple email will contain mailboxes without "task manager" features, while business email users will include it. Availability of the task manager will be triggered by hidden settings of the mailbox (APS service), which will be predefined by provider per offer. Customers will be able to buy simple email first, then they can choose to buy an upgrade to business email and to switch existing mailbox to new feature set – effectively it will mean reconfiguration of existing mailbox (APS service) with a different set of values in hidden settings.
It's important to note in the example above, that when buying an upgrade, the customer buys additional mailboxes, increasing total number of owned mailboxes. If it's necessary to keep the total number of mailboxes constant during such upgrade, APS metadata of the application must be different: "task manager" feature must be triggered by application child-component "task manager" (APS service) instead of hidden setting of mailbox. Thus, it's important to consider in advance, how each application feature will be sold: either as setting of application component or as its child-component.
