Share via


How is Service Provider Foundation associated with Service Management Automation?

 

Applies To: Windows Azure Pack

Service Provider Foundation integrates with the management portal for administrators and Microsoft System Center Virtual Machine Manager to provide capabilities to administer and provision virtual machines on the go. Service Provider Foundation can also be extended to integrate with other business operations and tool using Service Management Automation (a variant of System Center Orchestrator for management portal for administrators), to provide capabilities to service providers and organizations to extend their offerings. For example, you could think of a scenario where every time a service administrator changes an existing plan, you want to run an automated task that propagates that change across all pre-existing subscriptions of that plan. In this section, we look at the architecture and flow of how this integration is achieved.

When you register Service Management Automation, you register the endpoint of the server where the Service Management Automation web service is running. Registering the Service Management Automation endpoint enables you to associate Runbooks with the VM Clouds infrastructure as well as other general usage of automation.

Architecture for VM Clouds with Automation

After you have registered the Service Management Automation web service, the Runbooks created under the Automation tab (and that include “SPF” among one or more tag values), are available under the VM Clouds tab for associating with events in Service Provider Foundation. The VM Clouds tab already has a list of objects and corresponding events that can be associated with Runbooks. Let us understand how the communication happens between Service Provider Foundation and the SMA using an example. Assume that service administrators want to execute a Runbook, which deletes all the user resources on VMM, every time after a subscription is deleted. To achieve this, from the VM Clouds tab, the service administrator uses an existing object (e.g. Subscription), selects the appropriate action (e.g. Delete), and associates these with the Runbook (e.g. Delete-Subscription). Once this is done, every time a subscription is deleted, the following actions occur in the background:

  1. When the portal performs an operation using the Service Provider Foundation, Service Provider Foundation checks for a preconfigured action associated with operation. If there’s an associated action, Service Provider Foundation retrieves the Runbook information associated with that action.

  2. Service Provider Foundation makes the appropriate call to perform the intended operation, which as per the example, is to delete a subscription.

  3. Service Provider Foundation then goes ahead and invokes the associated Runbook using the Service Management Automation web service already registered with the portal. Here, even if the Runbook fails to execute, the Service Provider Foundation call to delete the subscription is not blocked.

  4. Finally, Service Provider Foundation sends the response for the core operation (deleting the subscription) back to the portal while the runbook executes because the automation is triggered asynchronously.

For information on how to register the Service Management Automation endpoint, see Register Service Management Automation for Virtual Machine Clouds. For information on how to associate objects and actions in Service Provider Foundation with runbooks, see Using automation with Virtual Machine Clouds.

See Also

Understanding the Virtual Machine Clouds architecture