1. Integrating with Inbound API
  2. Incremental Upload ‘data’ Node

Incremental Upload ‘data’ Node

The incremental upload 'data' contains a single child 'commands' which is an array of individual 'command' structures, as follows:

<data> 
	<commands> 
		<command></command> 
		<command></command> 
		<command></command> 
	</commands> 
</data>

  • 'command' structure

The 'command' structure consists of the following elements:

'command' structure fields

Name Required Type Description

type

Yes

enum

type of command to be performed

valid values:

'start_activity'; 'complete_activity'; 'notdone_activity'; 'suspend_activity'; 'update_activity'; 'cancel_activity'; 'delete_activity'; 'set_inventory'; 'update_inventory'; 'delete_inventory'

date

-

date

date of command in YYYY-MM-DD format; mandatory to create activity and defines the date to which the activity is to be assigned the field is processed in accordance with reschedule rules

If command date field is defined AND not empty, the activity is rescheduled to the date.

If command date field is not defined AND activity does not exist, command is rejected with message 'date is empty'.

If command date field is not specified AND activity already exists, command date is set to the existing activity date.

If command date field is defined but empty, the activity is non-scheduled.

Note: if a date is specified in the command request (whether it is empty or not) the activity will be rescheduled accordingly prior to its update / cancelation / deletion and if such a reschedule is not valid, the command will be rejected).

external_id

No

string key

indicates the resource, for which the command will be performed, if the resource is different from initial activity resource

if not specified, assigned to the existing activity resource

fallback_external_id

No

string key

indicates resource, for which the commands will be performed, if the resource specified by 'external_id' is not available (e.g. on holiday etc.). It must not be present when 'external_id' is absent. It functions in the same way as default activity pool: e.g. activity arrives with external_id=A, fallback_external_id=B, default_activity_pool=C

- A is checked and if A is available, activity is added to A

- if B is checked and if B is available, activity is added to B

- if C is checked and if C is available, activity is added to C

- if activity is not added it is empty by default

time

-

time

Operation time in YYYY-MM-DD HH:MM:SS format

optional for 'start_activity', 'complete_activity', 'notdone_activity' and 'suspend_activity' and meaningless for the rest. If not set for these operations, then default is used – current time in time zone of resource.

start_time for activity started with 'start_activity', and end_time for activities processed with 'complete_activity', 'notdone_activity' and 'suspend_activity' (for suspended)

appointment

-

struct

mandatory for activity-related commands and meaningless for the rest

array of 'appointment' structures that contain activity fields for activity update and cancel commands

inventories

-

struct

mandatory for inventory-related commands and meaningless for the rest

array of 'inventory' structures that contain list of inventories for this resource

userdata

No

string

string, returned in SOAP response without change; not used by the Inbound API, but intended for clients (e.g. to store an ID in SOAP request and then quickly find record in SOAP response using this ID)

default value: none

  • Incremental Upload 'data' Node Example

<data>
	<commands> 
		<command> 
			<date>2007-06-08</date> 
			<type>start_activity</type> 
			<time>2011-12-31 23:59:59</time> 
			<external_id>53305</external_id> 
			<fallback_external_id>AREA01</fallback_external_id> 
			<appointment> 
			</appointment> 
		</command> 
		<command> 
			<date>2007-06-08</date> 
			<type>set_inventory</type> 
			<external_id>53305</external_id> 
			<inventories> 
				<inventory/> 
				<inventory/> 
				<inventory/> 
			</inventories> 
		</command>
	</command>
</data>