The Maintenance and UsageServer processes share the same configuration file. The configuration file, named commerceserver.cfg, is located in the \ondemand directory of the server where the two processes are installed.
You can use any text editor to edit the file. The configuration settings are described below.
ldap.host: Specifies the IP address or DNS host name of the LDAP server through which the Maintenance and UsageServer processes access eDirectory.
ldap.loginName: Specifies the distinguished name of the user through which the Maintenance and UsageServer processes will authenticate to eDirectory. Use LDAP syntax to specify the name (for example, cn=admin,o=novell).
If the user name includes extended (multibyte) characters and the Maintenance and UsageServer processes are running on a NetWare server, you need to run commerceserver.cfg through the Java utility native2ascii. At the server console, enter the following:
native2ascii \ondemand\commerceserver.cfg
This needs to be done any time you change the user name.
ldap.useSSL: Specifies whether or not SSL will be used for the connection to the LDAP server. Values are TRUE and FALSE.
ldap.port.SSL: Specifies the SSL LDAP port number being used by the LDAP server. This port will be used if ldap.useSSL is set to TRUE. The standard SSL LDAP port is 636.
ldap.port.clearText: Specifies the non-SSL LDAP port number being used by the LDAP server. This port will be used if ldap.useSSL is set to FALSE. The standard non-SSL LDAP port is 389.
UsageHeartbeatMinutes: This setting is used by both the Maintenance and UsageServer processes to ensure accurate purchase records for packages with usage-based pricing schemes.
When a user launches a package's application, a Usage object is created under the Purchase object associated with the package. The Usage object contains a beginning time stamp created by the UsageServer. After each 10 minutes of use (the default), the UsageServer adds an interim time stamp called the heartbeat time stamp.
When the user exits the application, the UsageServer removes the heartbeat time stamp and creates the ending time stamp. However, if something happens during the time the user is using the application so that the UsageServer is unable to create the ending time stamp, the last heartbeat time stamp remains.
The Maintenance process, during its maintenance task, looks for any Usage objects with heartbeat time stamps that are older than 10 minutes. If this situation exists, it uses the heartbeat time stamp as the ending time stamp. This ensures that the user is not billed for more time than the UsageServer was actually able to record
MaintainEveryMinutes: Specifies how often the Maintenance process will read eDirectory to process any Purchase and Usage records. The default is every 10 minutes.
Take care when configuring this setting. One of the tasks the Maintenance process performs is to revoke a user's package rights when the user's purchase expires. If you set a long maintenance interval (for example, 600 minutes or 10 hours) and the purchase pricing scheme is Clock Time, a user will continue to have access to the purchased package for up to 10 hours after the user's purchased time ended (provided the user does not log out of NPS or refresh the Launch Item gadget's list). The extra time will depend on where the Maintenance process is in its time interval when the user's purchased time runs out. For example, if it performed maintenance 4 hours prior to the user's time running out, the user could continue to use the package for another 6 hours if he or she doesn't log out of NPS or update the Launch Item gadget.
DeletePurchasesPostExpirationDays: Specifies how long the Maintenance process will wait to delete a Purchase object after the purchase has expired and been billed for (as indicated by the Expired and Billed status boxes checked on the Purchase object). The default is 1 day. Enter 0 to have Purchase objects deleted immediately upon expiration and billing. Enter -1 to never delete expired Purchase objects.
DeleteUsagePostExpirationDays: Specifies how long the Maintenance process will wait to delete a Usage object after it has expired. The default is 1 day. Enter 0 to have Usage objects deleted immediately upon expiration. Enter -1 to never delete expired Usage objects.
DeletePendingRequestExpirationDays: Specifies how long the Maintenance process will wait to delete a Purchase object created for a purchase that is still pending approval or denial. The default is 1 day. Enter 0 to have pending Purchase objects deleted immediately. Enter -1 to never delete pending Purchase objects.
DeleteRequestInfoExpirationDays: This setting applies to subscription-based purchases only. It specifies how long the Maintenance process will wait to delete the purchase request information stored in the Purchase object. The default is 1 day. Enter 0 to have purchase request information deleted immediately upon approval or denial. Enter -1 to have purchase request information deleted only when the Purchase object is deleted.
baseContext: Specifies the context of the container that the Maintenance process will use as its root container. The Maintenance process will only process purchases located within the root container and its subcontainers. Use LDAP syntax to specify the root container (for example, ou=apps,ou=services,o=novell).
purchaseClassx: The Maintenance process is multi-threaded. One thread is used to process purchases (Purchase objects) and another thread is used to process usages (Usage objects). You can use the purchaseClassx setting to specify the Java classes that you want run during the purchase thread. Currently, there are two pre-defined classes that are used:
The order in which you specify the classes in the commerceserver.cfg file is the order in which they will be processed. In the following example, the purchaseClass1 entry is processed before the purchaseClass2 entry:
purchaseClass1 = RequestMaintain
purchaseClass2 = PurchaseMaintain
You can also develop your own Java classes and tie them in through the purchaseClassx property. For example, if you have a third-party billing or reporting system, you could write a Java class to read the Purchase object attributes and export them to the billing or reporting database. By entering the following property definition, the Maintenance process would run the Java class after the first two classes:
purchaseClass3 = PurchaseInfoExport
usageClassx: Specifies the Java classes that you want run during the Maintenance processes usage thread. Currently, there is one predefined class that is used:
The syntax is:
usageClass1 = UsageMaintain
As with the purchaseClassx property, you can tie in additional classes to perform tasks on Usage objects.