| Description | Manage Appointment Activities |
| Name | ManageAppointmentActivityIn |
| Namespace | http://sap.com/xi/A1S/Global |
| Process Component Description | Activity Management |
| Process Component Name | ActivityManagement |
| Process Component Namespace | http://sap.com/xi/AP/FO/Activity/Global |
| Deploymnent Unit Description | Foundation |
| Endpoint Activation | By Scoping of Process Component | Operations |
| Release Status | Deprecated |
An interface to migrate appointment activity data from a source system or a file.
The web service interface Manage Appointment Activity In enables you to connect external applications to your SAP system and to create and edit appointment activities within your system. The web service interface Manage Appointment Activity In is relevant if your company wants to access and manage appointment activity data from external applications.
The web service interface Manage Appointment Activity In offers the operations MaintainBundle and CheckMaintainBundle.
Here is an example of a simple web service request:
Show full documentation
Show full documentation
<n0:AppointmentActivityBundleMaintainRequest_sync_V1 xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
<BasicMessageHeader>
<ID>00000000000102dcade9bcb0aa000c68</ID>
</BasicMessageHeader>
<AppointmentActivity actionCode="01">
<Name>Meeting Preperation</Name>
<PriorityCode>1</PriorityCode>
<InformationSensitivityCode>1</InformationSensitivityCode>
<StartDateTime timeZoneCode="CET">2012-06-28T12:00:00.0000000Z</StartDateTime>
<EndDateTime timeZoneCode="CET">2012-06-30T12:00:00.0000000Z</EndDateTime>
<Text actionCode="01">
<TextTypeCode>10002</TextTypeCode>
<ContentText>Meeting Preparation for a new customer</ContentText>
<CreationDateTime>2006-03-28T12:00:00.1234567Z</CreationDateTime>
</Text>
<OrganizerParty>
<BusinessPartnerInternalID>MC2471</BusinessPartnerInternalID>
</OrganizerParty>
<EmployeeResponsibleParty>
<BusinessPartnerInternalID>MC2471</BusinessPartnerInternalID>
</EmployeeResponsibleParty>
<MainActivityParty>
<BusinessPartnerInternalID>MC9785</BusinessPartnerInternalID>
</MainActivityParty>
</AppointmentActivity>
</n0:AppointmentActivityBundleMaintainRequest_sync_V1>
Existence of referenced master data or business documents:
Employee, customer, and so on to name processor, or employee responsible for related customers
Campaigns or other business documents to reference
Maintain Bundle operations enable external applications to create and change business document data. Check Maintain Bundle operations enable external applications to simulate maintain bundle requests without changing business document data. In particular, Check Maintain Bundle operations have the following functions:
Return system messages similar to corresponding maintain bundle operations
Provide the same message type as the corresponding operation Maintain Bundle
Do not assign internal numbers from a productive number range interval (number range statuses are not increased)
Do not change business documents
Action codes represent an instruction to the recipient of the web service request to process transmitted message node elements.
| Action Code | Description |
|---|---|
| 01 | Create; the system returns an error message if the node element already exists. |
| 02 | Update; the system returns an error message if the node element does not exist. |
| 03 | Delete; the system returns an error message if the node element does not exist. |
| 04 | Save; the system creates or changes the node element data. |
| 05 | Remove; the system deletes the node element. If the node element does not exist, the system does not send an error message. |
| 06 | No Action; the system does not change the node element. |
Default action code: 04 (Save).
Note: Action code 04 (Save) creates business documents if the system could not identify a matching target business document. This applies in particular if no business document ID or UUID is provided by the web service consumer. The web service consumer (external application) is responsible for providing correct business document IDs or UUIDs, in order to avoid accidental creation of duplicate business documents.
The processing of node elements with cardinality > 1 (for example a list of descriptions in different languages or a list of telephone numbers) can be controlled using List Complete Transmission Indicators (LCTI). The LCTI indicates whether a list of node elements is transmitted completely. The LCTI of a node element with cardinality > 1 is modeled as an attribute of its parent node element (attribute name: <name of child element>ListCompleteTransmissionIndicator).
| LCTI | Description |
|---|---|
| false | The list of node elements is not completely transmitted. Hence, all node elements that are not transmitted remain unchanged. If transmitted node elements in the list can be uniquely identified, the system processes the node elements according the action code. If transmitted node elements in the list cannot be uniquely identified, the system appends the node element to the corresponding list of node elements in the target business document. |
| true | The list of elements is completely transmitted. Hence, all node elements that are not transmitted are removed. If no node element is transmitted, the complete list is removed. |
Default list complete transmission indicator: false.
Note: The LCTI refers to the completeness of the list of node elements and does not imply completeness of sub-elements.
Optional leaf elements in request messages that are not transmitted within a web service request are not changed in corresponding business documents.
Example
When updating an appointment activity, the request updates the name. The priority code remains unchanged, as the PriorityCode element is not contained in the XML document (commented out).
<AppointmentActivity actionCode="02"> <Name>Meeting Preperation</Name> <!-- <PriorityCode>1</PriorityCode> --> <InformationSensitivityCode></InformationSensitivityCode> </AppointmentActivity>
Note: The request tries to delete or update the information sensitivity code with its initial value (which would cause an error message as an initial value is not allowed for the information sensitivity code).
Maintain bundle and check maintain bundle operations are mass-enabled stateless synchronous web service operations. Transferring or requesting amounts of data that are too large causes communication timeouts. The web service consumer is responsible for ensuring reasonable sizes of data for mass operations.
Maintain bundle and check maintain bundle operations support exactly one execution (idem potency). To ensure exactly one execution of web service requests, the web service consumer has to provide unique values for the elements ID or UUID of the BasicMessageHeader node element.
Using change state identifier (element name ChangeStateID), external applications can enforce that a modifying operation is not executed because the state of the business document has changed since the external application last read its data.
The change state ID is an uninterpretable string that is provided by query and read operations and can be utilized by all modifying operations. If the change state identifier is provided when calling a modifying operation, then the system does not perform the operation if the state of the business document instance has changed since the change state ID was computed. If the change state ID is not provided by the web service consumer, the system performs the web service operation without checking the state of the business document.
The web service consumer (external application) is responsible for preventing accidental changes to business documents.
Note: For this web service, the change state ID does not apply to the ContactPerson, Relationship, CommunicationArrangement, DirectResponsibility, SalesArrangement, or PaymentData node elements.
Request node elements with cardinality > 1 contain an object node sender technical identifier to relate response message elements and log items to corresponding node elements in the request message.
The object node sender technical identifiers are provided as ObjectNodeSenderTechnicalID in request message types and referred to as ReferenceObjectNodeSenderTechnicalID in corresponding response message types.
If the object node sender technical ID is initial, the object node sender technical ID of the parent node element in the request is returned as the reference object node sender technical ID. If the object node sender technical IDs of all parent node elements are initial, the reference object node sender technical ID is returned as initial as well.
Note: The values specified in the ObjectNodeSenderTechnicalID are transient values that establish the correspondence between elements for only a single call. The web service consumer is not required to specify them or to use the same values for different calls. Also, the service provider does not interpret these values at all. Instead, the service provider returns them to the web service consumer in the ReferenceObjectNodeSenderTechnicalID elements.
Note: The ObjectNodeSenderTechnicalID is also used to identify failed business document modifications in a mass operation.
Example
Request:
<Child>
<ObjectNodeSenderTechnicalID>999_A<ObjectNodeSenderTechnicalID>
<Content>Child A: Some correct content</Content>
</Child>
<Child>
<ObjectNodeSenderTechnicalID>999_B<ObjectNodeSenderTechnicalID>
<Content>Child B: Some erroneous content</Content>
</Child>
Response:
<Log>
<Item>
<ReferenceObjectNodeSenderTechnicalID>999_B </ReferenceObjectNodeSenderTechnicalID>
<Note>Error message for Child B</Note>
</Item>
</Log>
The structure of the response message consists of two parts:
A business document-specific part containing information about IDs and UUIDs of the created and changed business documents
Log items containing system messages including errors, warnings, and information messages raised by the system during processing of the web service request
You can find general information about Web services, their structure and consumption in the Web Services documentation.
Possible scenarios include the following:
Create Appointment
The MaintainBundle_V1 operation is used to create an appointment
Update Appointment
The MaintainBundle_V1 operation is used to update existing appointment
Here is an example web service request to create an appointment activity:
<n0:AppointmentActivityBundleMaintainRequest_sync_V1 xmlns:n0="http://sap.com/xi/SAPGlobal20/Global"> <BasicMessageHeader> <ID>00000000000102dcade9bcb0aa000c68</ID> </BasicMessageHeader> <AppointmentActivity actionCode="01"> <ObjectNodeSenderTechnicalID>Token 14</ObjectNodeSenderTechnicalID> <Name>Preperation of Customer Presentation</Name> <PriorityCode>1</PriorityCode> <InformationSensitivityCode>1</InformationSensitivityCode> <CompletionPercent>29</CompletionPercent> <StartDateTime timeZoneCode="CET">2012-06-28T12:00:00.1234567Z</StartDateTime> <EndDateTime timeZoneCode="CET">2012-06-28T13:00:00.1234567Z</EndDateTime> <OrganizerParty> <BusinessPartnerInternalID>MC2471</BusinessPartnerInternalID> </OrganizerParty> <EmployeeResponsibleParty> <BusinessPartnerInternalID>MC2471</BusinessPartnerInternalID> </EmployeeResponsibleParty> <MainActivityParty> <BusinessPartnerInternalID>MC9785</BusinessPartnerInternalID> </MainActivityParty> </AppointmentActivity> </n0:AppointmentActivityBundleMaintainRequest_sync_V1>
As a request response, the ID of the created appointment activity is returned.
Here is an example of a web service request to update the name of an appointment activity:
<n0:AppointmentActivityBundleMaintainRequest_sync_V1 xmlns:n0="http://sap.com/xi/SAPGlobal20/Global"> <BasicMessageHeader> <ID>00000000000102dcade9bcb0aa000c99</ID> </BasicMessageHeader> <AppointmentActivity actionCode="02"> <ID>692</ID> <Name>Preperation of Customer Call</Name> </AppointmentActivity> </n0:AppointmentActivityBundleMaintainRequest_sync_V1>
Attention: The party ID and party role are not unique keys for a party instance. Thus, for parties with 1:n cardinality, in case of updates (change + delete) the CompleteTransmissionIndicator needs to be set and the whole list of updated parties that should replace the existing list of parties has to be provided.
Example data for ReferenceParty:
List of existing ReferenceParty to be changed:
MCP6049
MCPB9785
MCPC9785
What do we want to achieve?
Delete party MCP6049
Keep party MCPB9785
Change party MCPC9785 -> MCP17101
Add party MCP17102
Add party MDECP9786
Due to the fact that no unique idenfication of a party instance is possible using party ID and party role, the ReferencePartyListCompleteTransimissionIndicator is to be set to "true". Therefore, the behavior will be as follows: The list of parties is completely transmitted. Hence, all parties are removed that are not transmitted. If no party is transmitted, the complete list is removed.
In the following example, the desired list of parties is to be provided:
MCPB9785
MCP17101
MCP17102
MDECP9786
The respective XML document to achieve this looks like the following:
<n0:AppointmentBundleMaintainRequest_sync_V1 xmlns:n0="http://sap.com/xi/SAPGlobal20/Global"> <BasicMessageHeader> <ID>00000000000102dcade9bcb0aa000c68</ID> </BasicMessageHeader> <AppointmentActivity actionCode="02" referencePartyListCompleteTransimissionIndicator="true"> <ID>325</ID> <ReferenceParty> <BusinessPartnerInternalID>MCPB9785</BusinessPartnerInternalID> </ReferenceParty> <ReferenceParty> <BusinessPartnerInternalID>MCP17101</BusinessPartnerInternalID> </ReferenceParty> <ReferenceParty> <BusinessPartnerInternalID>MCP17102</BusinessPartnerInternalID> </ReferenceParty> <ReferenceParty> <BusinessPartnerInternalID>MDECP9786</BusinessPartnerInternalID> </ReferenceParty> </AppointmentActivity> </n0:AppointmentActivityBundleMaintainRequest_sync_V1>
In this case a new party instance has to be appended to the existing list of parties. This can be achieved by simply providing the new party and setting the ListCompleteTransimissionIndicator to "false".
Example data:
List of existing parties:
MCP6049
MCPB9785
MCPC9785
What do we want to achieve?
Keep MCP6049
Keep MCPB9785
Keep MCPC9785
Add MCP8300
Add MCP60500
In the following example, just the list of new parties has to be provided:
MCP8300
MCP60500
The respective XML document to achieve this looks like the following:
<n0:AppointmentActivityBundleMaintainRequest_sync_V1 xmlns:n0="http://sap.com/xi/SAPGlobal20/Global"> <BasicMessageHeader> <ID>00000000000102dcade9bcb0aa000c68</ID> </BasicMessageHeader> <AppointmentActivity actionCode="02" referencePartyListCompleteTransimissionIndicator="false"> <!-- append new party instances with LCTI = "false" --> <ID>325</ID> <ReferenceParty> <BusinessPartnerInternalID>MCP8300</BusinessPartnerInternalID> </ReferenceParty> <ReferenceParty> <BusinessPartnerInternalID>MCP60500</BusinessPartnerInternalID> </ReferenceParty> </AppointmentActivity> </n0:AppointmentActivityBundleMaintainRequest_sync_V1>
| Description | Maintain appointment activities |
| Name | MaintainBundle |
| Synchronous | yes |
| Release Status | Deprecated |
To create, update, or delete appointment activities.
The request message of the operation MaintainBundle contains a BasicMessageHeader node element as well as an AppointmentActivity node element that contains the task data to be created or updated. The task node can occur multiple times in the request message. This means that multiple activity tasks can be created and updated through a single web service request.
The response message type of the operation MaintainBundle contains log items, processing information, and an AppointmentActivity-specific node with ReferenceObjectNodeSenderTecnicalID, ChangeStateID. In addition, as AppointmentActivity InternalID and account UUID are also listed.
The AppointmentActivity node element contains all general task information such as ID, UUID, names, and other forms of identification.
The data for this node is related to general data on the appointment activity UI.
There is no InternalID element which can be set, because the UI is not showing such an ID anywhere. Nevertheless, it is generated in the backend. Therefore, the UUID element should be used to identify the appointment activity.
The ID is a unique identifier of the appointment. It is typically not shown in the UI, and is automatically generated by the system.
The UUID is a unique identifier of the appointment activity. It will be generated by the web service or can be provided by the consumer.
The Document Type Code which can be defined in the Business Configuration for Activities. If no special Document Type Code was defined in BC or shall be used, this Parameter can be ignored.
| MigratedDataAdaptationTypeCode | Description |
|---|---|
| 1 | Unchanged |
| 2 | Changed |
| 3 | Quantity |
| 4 | Items Changed or Omitted |
The attribute is the subject of the appointment activity as it will be shown in the UI.
The attribute specifies the priority of the activity task by the following codes:
| PriorityCode | Description |
|---|---|
| 1 | Immediate |
| 2 | Urgent |
| 3 | Normal |
| 7 | Low |
If not specified by the consumer, a default is set by the web service.
The attribute specifies the sensitivity of the activity task.
| InformationSensitivityCode | Description |
|---|---|
| 1 | Normal |
| 2 | Personal |
| 3 | Private |
| 4 | Confidential |
If not specified by the consumer, a default is set by the web service.
The attribute is used to group activity task under a certain aspect. The group code can be configured.
If not specified by the consumer, a default is set by the web service.
The attribute specifies the origin of the activity task.
| DataOriginTypeCode | Description |
|---|---|
| 1 | Manual Data Entry |
| 2 | Groupware |
| 3 | Direct Mailing |
| 4 | Telephony |
If not specified by the consumer, a default is set by the web service.
The attribute indicates roughly the status of the activity task.
| LifeCycleStatusCode | Description |
|---|---|
| 1 | Open |
| 2 | In Process |
| 3 | Completed |
If not specified by the consumer, a default is set by the web service.
The StartDateTime and EndDateTime specifies the period in which the activity task is scheduled for processing.
A timestamp for each DateTime has to be provided. Both dates have to be set together.
The Full Day Indicator has to be set for a full day appointment. In this case, the StartDateTime and EndDateTime get duration of 24 hours. The StartDateTime indicates the beginning of the day.
Parties can be provided and identified in various ways and not every option is available for every party:
| Description | |
|---|---|
| BPInternalID | Internal ID of the business partner |
| EmployeeInternalID | Internal employee ID of the business partner |
| EmailURI | EMailURI of the business partner. The EmailURI has to be uniquely assigned to a business partner. If this is not the case no identification is possible. If no party can be identified by the provided EmailURI, a party without ID is created with the EmailURI stored in a document address |
| Name | The Name cannot be used for identification. It will be stored in the address with a party that could not be identified by a given EmailURI |
The following Parties are available:
| Party | Description |
|---|---|
| Organizer Party | The organizer party is the party who craeated the appointment, for example, invited the attendees. It can be specified either by the business partner ID or the employee ID. |
| Attendee Party | The attendee party is the party who was invited to the appointment as a participant. It can be specified either by the business partner ID or the employee ID. |
| Employee Responsible Party | The employee responsible party is the employee who is responsible for the activity task. It can be specified either by the business partner ID or the employee ID. |
| Main Activity Party | The employee responsible party is the employee who is responsible for the activity task. It can be specified by the business partner ID |
| Reference Party | The reference party is the party to which the activity task is related. It can be specified either by the business partner ID or the employee ID. |
| Activity Unit Party | The activity unit party is an org unit, where the activity task is reported. It can be specified by the org center ID. |
By using the BusinessTransactionDocumentReference, the activity task can be linked to other business documents like an opportunity or campaign.
ID, UUID, and TypeCode of the related business document have to be provided, as well as the RefRoleCode specifying the type of relationship.
The most important RefRoleCodes are
| RefRoleCode | Description |
|---|---|
| 1 | Predecessor |
| 2 | Successor |
Example to link an opportunity as predecessor:
<BusinessTransactionDocumentReference> <ID>4711</ID> <TypeCode>72</TypeCode> <RoleCode>1</RoleCode> </BusinessTransactionDocumentReference>
Campaingns will always be linked as predecessors, independent of how the consumer specifies the RoleCode.
The attribute allows you to set texts for the activity task. The following text types are allowed:
| TextTypeCode | Description |
|---|---|
| 10002 | Activity Body |
| 10011 | Internal Comment |
While there is only one activity body (description of the activity task) allowed in an AppointmentActivity, there can be multiple internal comments. Therefore, for each internal comment, a timestamp as CreationDateTime can be provided to realize a sequence of comments.
Example:
<Text actionCode="01"> <TextTypeCode>10002</TextTypeCode> <ContentText>Prepare Customer Meeting...</ContentText> </Text> <Text actionCode="01"> <TextTypeCode>10011</TextTypeCode> <ContentText>Has to be clarified with Bob</ContentText> <CreationDateTime>2012-06-31T12:45:00.0000000Z</CreationDateTime> </Text> <Text actionCode="01"> <TextTypeCode>10011</TextTypeCode> <ContentText>Bob agrees</ContentText> <CreationDateTime>2012-06-31T12:55:00.0000000Z</CreationDateTime> </Text>
The AttachmentFolder node element can be used to add and remove activity task attachments.
Data for this node can be found on the activity task UI as attachments. On the user interface, files and links can be created. In the web service request, links and files are differentiated through the CategoryCode:
| Category code | Description |
|---|---|
| 2 | Document |
| 3 | Link |
The different types of attachments are differentiated by the TypeCode:
| Type code | Description |
|---|---|
| 10001 | Standard Attachment |
To create link attachments, document elements must be as follows:
| Element | Value |
|---|---|
| VisibleIndicator | true |
| CategoryCode | 3 |
| TypeCode | <none> |
| AlternativeName | <Document Title> |
| ExternalLinkWebURI | <link URI> |
| Description | <Comment> |
To create file attachments, document elements must be as follows:
| Element | Value |
|---|---|
| VisibleIndicator | true |
| CategoryCode | 2 |
| TypeCode | <none> |
| Name | <Document Title> |
| AlternativeName | <Document Title> |
| Description | <Comment> |
| Description | Check appointment activities |
| Name | CheckMaintainBundle |
| Synchronous | yes |
| Release Status | Deprecated |
To check if an appointment activity can be created, updated, or deleted without errors.
The web service request- and response message types for the CheckMaintainBundle operation are the same as those of the MaintainBundle operation. Therefore, the explanations given can also be applied to the CheckMaintainBundle operation.