Difference between revisions of "MCPServer"
(→Client) |
(Added schema to display structure of configurations.) |
||
| Line 51: | Line 51: | ||
===mcp Modules=== | ===mcp Modules=== | ||
| − | The mcp Modules are | + | The mcp Modules are configured in the database, with the following schema. |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | [[File:MCP_configuration_database_schema.png]] | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | File | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Client== | ==Client== | ||
Revision as of 16:36, 14 July 2011
Main Page > Development > Development documentation > MCP
Design
This page proposes a new feature and reviews design options
Development
This page describes a feature that's in development
Documentation
This page documents an implemented feature
Overview
The MCP is the Archivematica micro-services tool to control flow in the Archivematica system. It "knows" what things need to be done, who can do them, what is currently being processed across the distributed system, and is responsible for distributing the work. The user controls and monitors the MCP via the dashboard . The MCP maintains a log of all completed work.
The MCP is a client server based architecture. The clients are relatively "dumb". They inform the server what tasks they can perform, and wait for the server to assign them a task.
The system relies on client and server having access to the same directory, to process the commands.
Basic configuration can be seen here MCP Basic Configuration
Server
The server is the core of the MCP. It uses a set of modules, created at run time based on configurations (mcpModulesConfigs). These configs specify a directory to watch, and a series of commands to execute on anything placed in the directory.
Once a folder is placed in a watched the Directory a Job object is created. The Job has a UUID, and is an instance of a given module. If the job requires user approval, it waits till it receives it, otherwise it proceeds. The first thing an approved job will do is move the Event folder to the associated processing directory. The job has a number of steps, each step is associated with creating and executing the associated command from the comfig. If the job step is to execute on each file, it creates a task for each file, filtered by the specified filters. If the task is not to execute on each file, it creates a single task to execute on the directory.
Failure is defined as one or more exec Tasks or verification Tasks returned non zero.
Each task, like a job, has a UUID. Tasks are assigned to clients to perform. The clients inform the server of the tasks they can perform and the max number of threads they can handle. When a client completes a task, it will inform the server.
When the server is notified that a task is complete, it checks if that was the last task in the job step, and if it is, proceeds on to the next job step, until the job is done. When the job is done, the contents of the job processing folder are moved to their next location.
Each folder is separated in the processing folder by a sub folder named the job UUID. This allows for the Event folder to be renamed or otherwise manipulated.
Server Implementation
As stated above, the MCP watches directories specified in the modules, and has a set of commands to issue on items placed in those folders. Those commands will not be performed by the MCP server itself, but rather delegated to a client.
mcp Modules
The mcp Modules are configured in the database, with the following schema.
Client
Clients connect to the MCP and provide a list of modules they support. The MCP can then assign tasks, of supported types, to that client. The client reports the outcome of the task back to the MCP, once the task is completed.
Client on Windows
There has been some consideration of getting an MCP client to run in the Microsoft Windows environment. This would be advantageous for normalizing in a windows environment. Some testing has been done to this end. See issue 372.