Introduction to the Atos Automation Framework
This page provides a high level overview of the Automation Framework as available within the Atos Platform offering. The documentation also provides detailed information on how to implement Actions for the Automation Framework. The audiences for this document are solution architects and SharePoint developers.
With the Automation Framework, Atos offers customers the ability to perform administrative tasks on their SharePoint farms, without requiring access to the servers, PowerShell or additional administrative privileges. It allows the customer to schedule custom designed and developed tasks, called "Actions", on every Microsoft Windows based system in the service landscape. This includes not only SharePoint Servers, but can also include IIS servers (hosting provider hosted apps), Office Web Apps servers and others.
Custom Actions are developed using the Microsoft .NET framework. The Action Framework executes these actions using high privileges, which one would normally not have in such a hosted environment. Because of that these Actions can not only benefit but also potentially harm a system or the whole service. It's for that reason that Atos, as the service provider, follows a process for Action Development and Quality Assurance.
Custom Actions developed by Atos can be available either for specific customers, or as part of the common service shared by all customers. When a customer requires a specific Action, the following options are available:
- The customer can request Atos to develop a custom Action.
- The customer can develop their own Action and submit it to Atos in order to get it reviewed.
- Third party development
High Level Architecture
Figure 1: Automation Framework High Level Architecture
Figure 1 illustrates the high level architecture of the Automation Framework that utilizes a SOA (Service Oriented Architecture) approach. In the top part of the diagram we see the Admin Service clients installed on Windows based servers. Note that these do not necessarily have to be SharePoint servers; we can also include IIS or Office Web Apps servers for instance.
The TeamWeb DB is the database which is the central repository for all stored data. This data powers the Action Framework, Self Service Customer Portal, internally used IT Service Management Suite and is made available via several Web Services.
A couple of client applications (Customer Portal, Mobile App, etc.) have been included in the bottom half of the diagram to show how the same data is being used to power both the Action Framework as well as these applications.
Example use case: The Mobile App can invoke the Customer Web Servicet hat gets its data from the TeamWeb database. That way, the app can display information which was generated by a custom Action running on the SharePoint farm.
The Web Services are implemented using the industry standard SOAP (Simple Object Access Protocol) protocol. This allows for all kinds of integration scenarios to retrieve or push data from a target system.
Example use case: the Customer is able to invoke the Customer Web Service and add an Action schedule for the Site Creation Action. The Admin Service on the SharePoint system will poll the Web Service and retrieves the newly added schedule. Based on the schedule data, the Action will then be executed on the desired time, creating a new site collection with the supplied parameters. Output from the Action will be written back into the database which can then be viewed by the user using the Self Service Portal.
This extensible framework allows our customers to run one-time or recurring Actions which they can create themselves. This is a unique offering which bridges the gap between a self-managed on-premises installation of SharePoint and hosted offering in which customer do not have the ability to execute "full-trust" code.
To learn more about our unique automation framework, please sign in to this portal.