Retrieving Migration Status

After starting a migration, you can get information on its current status by sending a request packet with the get_status operation node which should include the migration unique identifier returned by the start operation.

Request Packet Structure

A request XML packet retrieving information on the migration status includes the get_status operation node:

<packet version="1.6.0.2">
<migration>
  <get_status>
  ...
  </get_status>
</migration>
</packet>

The get_status node is presented by complex type MigrationId (migration_input.xsd), and its graphical representation is as follows:

• The migration_id node is required. It holds the unique identifier of the migration. Data type: none.
• With one get_status operation, you can get information on the progress of a single migration. To retrieve information on multiple migrations with one packet, use the required number of the get_status nodes in your request packet.

Response Packet Structure

The get_status node of the response packet is structured as follows:

• The result node is required. It wraps the result of the get_status operation. Data type: MigrationOutputGetStatusResultType (migration_agent_output.xsd).
• The status node is required. It returns the execution status of the get_status operation. Data type: string. Allowed values: ok | error.
• The errcode node is required if the operation fails. It returns the error code when the get_status operation fails. Data type: unsignedInt.
• The errtext node is required if the operation fails. It returns the error message if the get_status operation fails. Data type: string.
• The migration_status node is required if the get_status operation succeeded and the migration is still in progress. It holds the collection of data describing the current status of the migration. Data type: MigrationStatus (plesk_migration.xsd). See the node structure below.
• The finished node is required if the get_status operation succeeded and the migration has been finished.The finished node is of MigrationFinishedType (migration_output.xsd). See the node structure below.

The migration_status node is structure as follows:

• The total node is required if the get_status operation succeeded and the migration is still in progress. It holds the number of all the internal items which are involved in the process of migration. The more objects are migrated, the bigger value is returned by the total node. Data type: integer.
• The completed node is required if the get_status operation succeeded and the migration is still in progress. It specifies how many migration items out of the total have already been migrated. Data type: integer.
• The description node is optional. It returns description of the current migration step if this information is available. Data type: string.

The finished node is structured as follows:

• The success node is optional. It is present in a response packet if the operation succeeded. Data type: none.
• The error node is optional. If an error occurs during the migration, it contains the error details. Data type: ErrorType (migration_output.xsd). The following nodes are required only in case of a migration error occurrence:
  • The message node is optional. It contains the error message. Data type: string.
  • The object node is optional. It contains type of the object caused the error. Data type: ObjectErrorType (migration_output.xsd).
  • The type node is optional. It contains type of the object caused the error. Data type: string.
  • The name node is optional. It contains name of the object caused the error. Data type: string.
  • The message node is oprional. It contains the error message. Data type: string.

Sample

This packet retrieves the status of migration with ID 12345.

<packet version="1.6.0.2">
<migration>
   <get_status>
      <migration_id>12345</migration_id>
   </get_status>
</migration>
</packet> 

Response::

<packet version="1.6.0.2">
<migration>
<get_status>
   <result>
      <status>ok</status>
      <migration_status>
         <total>33</total>
         <completed>10</completed>
      </migration_status>
   </result>
</get_status>
</migration>
</packet>

Responses received from server where migration is successfully finished look as follows:

<packet version="1.6.0.2">
<migration>
<get_status>
   <result>
      <status>ok</status>
      <finished><success/></finished>
   </result>
</get_status>
</migration>
</packet>

<packet version="1.6.0.2">
<migration>
<get_status>
   <result>
      <status>ok</status>
      <finished>
         <success/>
      </finished>
   </result>
</get_status>
</migration>
</packet>

A response received from server where migration is finished with errors can look as follows:

<packet version="1.6.0.2">
<migration>
<get_status>
   <result>
      <status>ok</status>
      <finished>
         <error>
            <object>
               <type>domain</type>
               <name>example.com</name>
            </object>
            <message>Error in physical hosting updating: permission denied</message>
         </error>
      </finished>
   </result>
</get_status>
</migration>
</packet>

This packet retrieves the status of migrations with IDs 24175 and 24176.

<packet version="1.6.0.2">
<migration>
   <get_status>
      <migration_id>24175</migration_id>
   </get_status>
   <get_status>
      <migration_id>24176</migration_id>
   </get_status>
</migration>
</packet>