Microsoft Provisioning Framework (MPF) has provisioning engine servers that act as transaction coordinators, routing real-time provisioning requests to called providers. The engine provides a framework for integrating multiple actions into a single transaction. The engine maintains contextual information and transaction state. After a failure, it also issues rollback calls and manages rollback data for actions subject to rollback.
The provisioning engine supports the following transaction models:
MPF setup installs Provisioning Engine in Windows Component Services, COM+ Applications. An MPF installation can have one or more engine servers.
Requests enter provisioning engines via a client. The interfaces IProvEngine::SubmitRequest and IProvEngine::SubmitTrustedRequest pass requests directly to the engine. The IProvQueue::SubmitRequest and IProvQueue::SubmitTrustedRequest interfaces pass queued requests to a queue manager, which submits them to a provisioning engine when it is time to process them.
Each request is a set of calls to one or more procedures defined as part of a in the configuration database. As the engine executes a procedure call, it acts on the incoming data by executing the XSL transformations and conditional operations defined in the procedure. For more information, see Provisioning Schema. The engine sends the current state of executing transactions to transaction logs in order to roll back the transactions after a failure.
The behavior of provisioning engines is configurable as follows.
|Requests Security||This property controls which users and groups can submit
requests to provisioning engines and the type of requests they can
submit. Options for submitting requests include the following. A
caller can have multiple access permissions.
|Audit Level||Flag that marks a procedure for auditing. During transaction
processing, provisioning engines initially move all transactions to
a transaction log. Periodically, an auditing and
recovery manager will clear the log and moves transactions for
audited procedures to the .
You have the following options for saving data to the audit log. Note that you can select more than one option. However, be aware that one setting can override another. For example, if you set both Transactions with errors and All transactions, the latter would prevail.
Data stored for procedures includes the transaction identifier, step number, namespace, and procedure name. Data stored for errors includes the transaction identifier, source, error code, and event description.
The transaction settings determine which kinds of transactions to audit.
The remaining settings determine what kinds of data to pass to the audit log for the transactions marked for audit.
|Enable Schema Validation||Specifies whether to validate XML data passed to procedures in
client requests against the input/output schema in the
corresponding procedure definitions. If validation fails, MPF
returns an error to the caller.
Important Enable schema validation only when testing new functionality. If you enable schema validation in a production environment, you might experience significant performance problems.
|Transaction Log Pool Size||Specifies the maximum number of connections that can be established to one transaction log database. The default setting is 100 simultaneous connections.|
|Tran Log Timeout||Time to wait (seconds) before a provisioning engine places a
malfunctioning connection to a transaction log server on a bad
server list. The default setting is 300 seconds.
Provisioning engines save the state of requests in progress to a transaction log server. If the network connection or the server fails while transactions are in process, MPF continues executing against the server until the transaction log timeout is reached. If the server does not come back online, MPF executes rollback and routes the transaction to the next available transaction log server (if any).