Show full documentation

 Show full documentation

Definition

An interface to create, update, or read data from a service request.

Business Context and Use

This web service is used to maintain service requests with data from an external consumer.

It has the MaintainBundle and the CheckMaintainBundle operations. The MaintainBundle operation is used to create or update one or more instances of the service request. The CheckMaintainBundle operation is used to check if the one or more instances of the service request can be maintained.

The signatures of the two operations are identical.

Example

The following example creates a service request with an incident description:

<n0:ServiceRequestBundleMaintainRequest2_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
 <BasicMessageHeader>
     <ID>00163E028B341EE1B1CFC25D36A06174</ID>
 </BasicMessageHeader>
 <ServiceRequest actionCode="01">
  <Name>Unexpected behaviour when ...</Name>
  <DataOriginTypeCode>4</DataOriginTypeCode>
  <BuyerParty contactPartyListCompleteTransmissionIndicator="true">
   <BusinessPartnerInternalID>MC6049</BusinessPartnerInternalID>
   <ContactParty actionCode="01">
    <BusinessPartnerInternalID>MCP6049</BusinessPartnerInternalID>
    <MainIndicator>true</MainIndicator>
   </ContactParty>
  </BuyerParty>
  <Text>
   <TypeCode>10004</TypeCode>
   <CreationDateTime>2012-03-28T12:00:00Z</CreationDateTime>
   <Content>When switching on the device, it unexpectedly ..</Content>
  </Text>
 </ServiceRequest>
</n0:ServiceRequestBundleMaintainRequest2_sync>

Prerequisites

Technical Prerequisites:

This web service must be activated within a communication arrangement maintained for the scenario Manage Service Requests.

Existence of master data:

All master data are only referenced, and will not be created by the service operations. They must already exist in the system at the time the web service is called:

• Organizational Management Data

• Employees and Responsibilities

• Products used as Reference Objects

• Customers

• Service Issue Categories

• Service Levels

Constraints and Integrity Conditions

General Rules for Using this Web Service

Check Maintain Bundle vs. Maintain Bundle

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 status is not increased)

• Do not change business documents

Action Code

Action Code is a coded representation of an instruction to the recipient of a message telling them how to process a transmitted node or element. It is modeled as an attribute (attribute name: actionCode) in structure elements of the message payload.

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 and avoiding accidental creation of duplicate business documents.

Example

  <Text actionCode="01">
   <TypeCode>10004</TypeCode>
   <Content>When switching on the device, it unexpectedly ..</Content>
  </Text>

List Processing

The processing of node elements with cardinality > 1 (for example a list of texts or a list of solution proposals) can be controlled using List Complete Transmission Indicators (LCTI). The LCTI indicates whether a list of node elements is completely transmitted. The LCTI of a node element with cardinality > 1 is modeled as 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 of 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.

Example

The following example deletes all existing texts, except the text specified by the ID, and adds a new incident description (text type 10004):

<ServiceRequest actionCode="02" textListCompleteTransmissionIndicator="true">
  <ID>2010041753</ID>
  <Text>
   <TypeCode>10004</TypeCode>
   <CreationDateTime>2012-03-28T12:00:00Z</CreationDateTime>
   <Content>New Incident Description: When switching off the device, it unexpectedly ..</Content>
  </Text>
  <Text actionCode="06">
   <ID>00163E028B121ED1B2D287F8D2B9E1AA00163E028B121ED1B2D29D7C425FA1D4T00002</ID>
  </Text>
 </ServiceRequest>

Empty and Missing Elements

Optional leaf elements in request messages that are not transmitted within a web service request are not changed in corresponding business documents.

Example

Only the name element of the service request is updated. The data origin type code (commented out), as well as the other elements (not contained) remain unchanged.

 <ServiceRequest actionCode="02">
  <ID>2010041753</ID>
  <Name>changed name</Name>
  <!-- <DataOriginTypeCode>4</DataOriginTypeCode> -->
  <MainIncidentServiceIssueCategory>
   <ServiceIssueCategoryID></ServiceIssueCategoryID>
  </MainIncidentServiceIssueCategory>
 </ServiceRequest>

Note: The request deletes the incident service issue category ID, or updates the incident service issue category ID with its initial value.

Communication Timeout

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 for mass operations.

Message Header

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 must provide unique values for the elements ID or UUID of the “BasicMessageHeader” node element.

Change State ID

Using the 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, 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.

Object Node Sender Technical Identifier

Request node elements with cardinality > 1 contain 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 are 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 only for 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:

<Root>
<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>

Response Message

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

More Information

General Information

You can find general information about Web services, their structure and consumption in the Web Services documentation.

Scenarios

Possible scenarios include the following:

• Create Service Requests

Operation_MaintainBundle_ is used to create service requests.

• Update Service Requests

Operation_MaintainBundle_ is used to update existing service requests.

For a complete roundtrip, service interface QueryServiceRequestIn can be used to read service request data.

Examples

Create a new service request with an incident description from the internet:

Request message:

<n0:ServiceRequestBundleMaintainRequest2_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
 <BasicMessageHeader>
     <ID>00163E028B341EE1B1CFC25D36A06174</ID>
 </BasicMessageHeader>
 <ServiceRequest actionCode="01">
  <Name>Unexpected behaviour when ...</Name>
  <DataOriginTypeCode>4</DataOriginTypeCode>
  <BuyerParty contactPartyListCompleteTransmissionIndicator="true">
   <BusinessPartnerInternalID>XC6049</BusinessPartnerInternalID>
  </BuyerParty>
  <Text>
   <TypeCode>10004</TypeCode>
   <Content>When switching on the device, it unexpectedly ..</Content>
  </Text>
 </ServiceRequest>
</n0:ServiceRequestBundleMaintainRequest2_sync>

Response message:

<nm:ServiceRequestBundleMaintainConfirmation2_sync xmlns:nm="http://sap.com/xi/SAPGlobal20/Global">
 <ServiceRequest>
  <ReferenceObjectNodeSenderTechnicalID> </ReferenceObjectNodeSenderTechnicalID>
  <ChangeStateID>                 20120725092834.8682090</ChangeStateID>
  <UUID>00163e02-8b2e-1ed1-b5c7-635c38e93c1b</UUID>
  <ID>2010042048</ID>
 </ServiceRequest>
 <Log/>
</nm:ServiceRequestBundleMaintainConfirmation2_sync>

Update the message with additional information provided by the customer:

Request message:

<n0:ServiceRequestBundleMaintainRequest2_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
  <BasicMessageHeader>
    <ID>00163E028B2E1ED1B5C8C39225E81F31</ID>
  </BasicMessageHeader>
  <ServiceRequest actionCode="02">
    <ChangeStateID> 20120725092834.8682090</ChangeStateID>
    <ID>2010042048</ID>
    <Text actionCode="01">
      <TypeCode>10008</TypeCode>
      <Content>... additional info from customer...</Content>
    </Text>
  </ServiceRequest>
</n0:ServiceRequestBundleMaintainRequest2_sync>

Read the service request:

Request message:

<n0:ServiceRequestByElementsQuery_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
 <ServiceRequestSelectionByElements>
  <SelectionByID>
   <InclusionExclusionCode>I</InclusionExclusionCode>
   <IntervalBoundaryTypeCode>1</IntervalBoundaryTypeCode>
   <LowerBoundaryIdentifier>2010042048</LowerBoundaryIdentifier>
  </SelectionByID>
 </ServiceRequestSelectionByElements>
 <ProcessingConditions>
  <QueryHitsUnlimitedIndicator>true</QueryHitsUnlimitedIndicator>
 </ProcessingConditions>
 <RequestedElements serviceRequestTransmissionRequestCode="1">
 </RequestedElements>
</n0:ServiceRequestByElementsQuery_sync>

Response message:

<nm:ServiceRequestByElementsResponse_sync xmlns:nm="http://sap.com/xi/SAPGlobal20/Global">
 <ServiceRequest>
  <ID>2010042048</ID>
  <UUID>00163e02-8b2e-1ed1-b5c7-635c38e93c1b</UUID>
  <SystemAdministrativeData>
   <CreationDateTime>2012-07-25T09:28:34.868209Z</CreationDateTime>
   <CreationIdentityUUID>00163e02-33f4-1ee1-81aa-311337aaf912</CreationIdentityUUID>
   <LastChangeDateTime>2012-07-25T10:51:58.914154Z</LastChangeDateTime>
   <LastChangeIdentityUUID>00163e02-33f4-1ee1-81ab-311337aaf912</LastChangeIdentityUUID>
  </SystemAdministrativeData>
  <Name>Unexpected behaviour when ...</Name>
  <DataOriginTypeCode>4</DataOriginTypeCode>
  <LifeCycleStatusCode>1</LifeCycleStatusCode>
  <BuyerParty>
   <BusinessPartnerInternalID>MC6049</BusinessPartnerInternalID>
   <ContactParty>
    <BusinessPartnerInternalID>MCP6049</BusinessPartnerInternalID>
    <MainIndicator>true</MainIndicator>
   </ContactParty>
  </BuyerParty>
  <ProcessorParty>
   <BusinessPartnerInternalID>MC2267</BusinessPartnerInternalID>
  </ProcessorParty>
  <ServiceSupportTeamParty>
   <OrganisationalCentreID>MC45310</OrganisationalCentreID>
  </ServiceSupportTeamParty>
  <TimePointTerms>
   <RequestInitialReceiptTimePoint timeZoneCode="UTC">2012-07-25T09:28:34Z</RequestInitialReceiptTimePoint>
   <FirstReactionDueTimePoint timeZoneCode="UTC">2012-07-27T21:00:00Z</FirstReactionDueTimePoint>
   <CompletionDueTimePoint timeZoneCode="UTC">2012-08-06T21:00:00Z</CompletionDueTimePoint>
  </TimePointTerms>
  <DurationTerms>
   <MaximumFirstReactionDuration>P1D</MaximumFirstReactionDuration>
   <MaximumCompletionDuration>P3D</MaximumCompletionDuration>
  </DurationTerms>
  <ServiceTerms>
   <ServicePriorityCode>3</ServicePriorityCode>
  </ServiceTerms>
  <Text>
   <ID>00163E028B2E1ED1B5C7635C38F25C1B00163E028B2E1ED1B5C7635C38F27C1BT00001</ID>
   <TypeCode>10004</TypeCode>
   <Content>When switching on the device, it unexpectedly ..</Content>
  </Text>
  <Text>
   <ID>00163E028B2E1ED1B5C7635C38F25C1B00163E028B2E1ED1B5C8CEC36BF4DF34T00002</ID>
   <TypeCode>10008</TypeCode>
   <Content>... additional info from customer...</Content>
  </Text>
 </ServiceRequest>
 <ProcessingConditions>
  <ReturnedQueryHitsNumberValue>1</ReturnedQueryHitsNumberValue>
  <MoreHitsAvailableIndicator>false</MoreHitsAvailableIndicator>
  <LastReturnedObjectID>00163E028B2E1ED1B5C7635C38E93C1B</LastReturnedObjectID>
 </ProcessingConditions>
</nm:ServiceRequestByElementsResponse_sync>

The most important information like ID, texts, initial receipt time point, priority. and status might be exposed to the end user who created the request.

 Show full documentation

 Show full documentation

Definition

To create and update one or more service requests using imported structured data.

Business Context and Use

This operation is used to create or update one or more instances of a service request.

The request message of the operation MaintainBundle contains a BasicMessageHeader node element, as well as a ServiceRequest node element containing the service request data to be created or updated. The detailed structure of the service request node will be explained in the following sub-chapters. The service request node can occur multiple times in the request message, meaning that multiple service requests can be created and updated by a single web service call.

The response message of the operation MaintainBundle contains log items, processing information, and a service request-specific node with ReferenceObjectNodeSenderTechnicalID, ChangeStateID; as well as service request ID and service request UUID.

Structure

Service Request

The Service Request node element contains basic information about the service request such as ID, name, data origin type code, and status. These fields can be found in the list of tickets in the customer service work center, or they will appear when creating a new ticket. The Service Request corresponds to the Ticket. The Name element corresponds to the Subject, or Description element on the user interface. The UUID element is not visible on the UI, but can be retrieved via web service Query Service Request In.

Note: When creating service requests via this operation, the service request ID is internally determined by the system. However, the service request ID element can (and must) be specified when creating service requests in data migration.

Note: The service request UUID is read-only, and cannot be set by an external application when creating service requests.

Note: Either UUID or ID can be used to specify a service request which shall be updated or deleted.

Example

Update a service request, identified via UUID, with a different subject:

<ServiceRequest actionCode="02">
  <UUID>00163E02-8B32-1EE1-B0A3-DF295AA5FD40</UUID>
  <Name>changed subject</Name>
</ServiceRequest>

Example

Update a service request, identified via ID, with a different subject:

<ServiceRequest actionCode="02">
  <ID>2001</ID>
  <Name>changed subject</Name>
</ServiceRequest>

The ProcessingTypeCode element can be found as Ticket Type in the UI. It can be specified only when a service request is created. Updating the ticket type for an existing service request is not possible.

The values are defined in business configuration. At least the following value for the processing type code exists:

Type Code	Description
SRRQ	Service Request

Note: When a service request is created without specifying the ProcessingTypeCode element, it will be set to its default value SRRQ.

Example

Create a service request with a customer-defined processing type code:

<ServiceRequest actionCode="04">
  <ProcessingTypeCode>ZRRQ</ProcessingTypeCode>
  <Name>Subject for ticket type ZRRQ</Name>
</ServiceRequest>

The data origin type code is a coded representation of where the service request data originates.

The following values for the data origin type code can exist:

Type Code	Description
1	Manual data entry
2	B2B message
3	A2A message
4	Internet
5	E-Mail
6	Social Media
7	Chat

The default value is 1.

Example

Specify that a service request has been created from the internet:

<DataOriginTypeCode>4</DataOriginTypeCode>

The ContractUsageRestrictionCode element can be used to restrict the context in which contracts can be used. The possible values are defined in business configuration. When no contract restriction is specified, it can be defaulted from the ticket type, as maintained in business configuration.

The lifecycle status code can occur with the following values:

Status Code	Description
1	Open
2	In Process
3	Completed
4	Closed

Note: Do not specify the LifeCycleStatusCode element when a completely new service request shall be created. The lifecycle status will be automatically set to its default value 1.

Note: When the lifecycle status code is used, the system will check if the corresponding action is allowed for this service request. If not, the system will return an error message.

Note: The status displayed in the ticket UI is no longer the LifeCycleStatusCode element but the UserLifeCycleStatusCode element found in the ServiceTerms node element. You do not have to specify the LifeCycleStatusCode element if you want to align with the UI.

If the LifeCycleStatusCode element is specified together with the UserLifeCycleStatusCode element, the system checks if the status combination is valid.

The escalation status code can occur with the following values:

Escalation Status Code	Description
1	Not Escalated
2	Escalated

Example

Specify that a service request is escalated:

<EscalationStatusCode>2</EscalationStatusCode>

Note: When a service request is created without specifying the escalation status code, it will be set to its default value 1.

The approval status code can occur with the following values:

Approval Status Code	Description
1	Not Started
2	Approval Not Necessary
3	In Approval
4	Approved
6	In Revision
7	Withdrawn

Example

Submit a service request for approval:

<ApprovalStatusCode>3</ApprovalStatusCode>

Note: When a service request is created without specifying the approval status code, it will be set to the appropriate value. If the service request is relevant for approval, this value is 1, if not, the value is 2.

Business Transaction Document Reference

Using the Business Transaction Document Reference node element enables you to specify external references for the ticket.

The Business Transaction Document Reference ID identifies the referenced document with the ID in the external system.

Supported values for the Business Transaction Document Reference Type Code are:

Type Code	Description
001	Purchase Order
005	Credit Memo (SRM)
8	Business Transaction (For Accounting)
12	Appointment
28	Customer Invoice
30	Sales Quote
32	Customer Return
39	E-Mail
50	Fax
64	Lead
65	Letter
72	Opportunity
73	Outbound Delivery
86	Phone Call
114	Sales Order
115	Service Confirmation
117	Service Order
118	Ticket / Service Request
542	Activity Task
764	Campaign
1092	Customer Contract
1452	Project Processing View of Customer Transaction Document
1485	Employee Expenses
1607	Social Media Activity
2004	Contract
2049	Messaging Activity

The Business Transaction Document Relationship Role Code can have the following values:

Role Code	Description	Remark
1	Predecessor
2	Successor
3	Used	(for contract reference)

Specify a valid value for the Business System ID element. A communication system can contain a Business System ID when it is flagged as SAP Business Suite system. Communication systems are available in the Administrator Workcenter.

Example

Add a reference to an external sales order:

  <BusinessTransactionDocumentReference actionCode="01">
   <BusinessTransactionDocumentReferenceID>501</BusinessTransactionDocumentReferenceID>
   <BusinessTransactionDocumentReferenceTypeCode>114</BusinessTransactionDocumentReferenceTypeCode>
   <BusinessTransactionDocumentRelationshipRoleCode>1</BusinessTransactionDocumentRelationshipRoleCode>
   <BusinessSystemID>EXT_SYS</BusinessSystemID>
  </BusinessTransactionDocumentReference>

The InternalIndicator is to be specified with value true if the referenced business transaction document is within the same system as the ticket. In this case, the Business System ID element must not be specified.

Note: For internal documents not all type codes are supported. The system currently offers the following document type codes:

Type Code	Description
12	Appointment
30	Sales Quote
39	E-Mail
64	Lead
72	Opportunity
86	Phone Call
118	Ticket / Service Request
542	Activity Task
764	Campaign
1607	Social Media Activity
1876	Questionnaire / Survey
2004	Contract
2049	Messaging Activity

The Business Transaction Document Reference Item UUID and Business Transaction Document Reference Item Type Code elements are needed to specify the reference to a valuation collection of a questionnaire, in the UI called survey.

For the valuation collection, the Business Transaction Document Reference Item Type Code element has the value 38710. The Business Transaction Document Relationship Role Code shall be specified as 2 (successor).

Note: Other use cases for using the Business Transaction Document Reference Item UUID and Business Transaction Document Reference Item Type Code elements are currently not supported.

Example

Add an existing valuation collection for questionnaire 1711:

  <BusinessTransactionDocumentReference actionCode="01">
   <ObjectNodeSenderTechnicalID>BTD1</ObjectNodeSenderTechnicalID>
   <BusinessTransactionDocumentReferenceID>1711</BusinessTransactionDocumentReferenceID>
   <BusinessTransactionDocumentReferenceTypeCode>1876</BusinessTransactionDocumentReferenceTypeCode>
   <BusinessTransactionDocumentReferenceItemUUID>00163E07-C021-1EE4-97B7-E58BF5D17BDF</BusinessTransactionDocumentReferenceItemUUID>
   <BusinessTransactionDocumentReferenceItemTypeCode>38710</BusinessTransactionDocumentReferenceItemTypeCode>
   <BusinessTransactionDocumentRelationshipRoleCode>2</BusinessTransactionDocumentRelationshipRoleCode>
   <InternalIndicator>true</InternalIndicator>
  </BusinessTransactionDocumentReference>

Buyer Party and Contact Party

The Buyer Party node element contains basic information about the customer for which the service request has been created. The BusinessPartnerInternalID element corresponds to the customer ID in the user interface.

The Contact Party and Main Contact Party node elements contain basic information about the contact persons for a customer. The BusinessPartnerInternalID element is the contact ID. In the Contact Party node element, the MainIndicator element specifies the main contact.

Note: If you do not specify the contact when creating a service request, the system will automatically determine the main contact from the customer master data.

Example

Specify a customer ID with a main contact deviating from the customer master data, using the Contact Party node element:

  <BuyerParty>
   <BusinessPartnerInternalID>XC6049</BusinessPartnerInternalID>
   <ContactParty>
    <BusinessPartnerInternalID>XY123</BusinessPartnerInternalID>
    <MainIndicator>true</MainIndicator>
   </ContactParty>
  </BuyerParty>

Example

Specify a customer ID with a main contact deviating from the customer master data, using the Main Contact Party node element:

  <BuyerParty>
   <BusinessPartnerInternalID>XC6049</BusinessPartnerInternalID>
   <MainContactParty>
    <BusinessPartnerInternalID>XY123</BusinessPartnerInternalID>
   </MainContactParty>
  </BuyerParty>

Note: On the UI, only the main contact is displayed.

The Main Contact Party node element addresses the main contact only. It can be used to replace a main contact by another one.

Note: Specify either the Contact Party or the Main Contact Party node element but not both at the same time. If both are filled, an error message is returned.

Note: If the Main Contact Party is used, the contactPartyListCompleteTransmissionIndicator needs not to be set.

Example

Replace the main contact, and leave all other contacts as they are, if existing:

  <BuyerParty>
   <MainContactParty>
    <BusinessPartnerInternalID>YZ456</BusinessPartnerInternalID>
   </MainContactParty>
  </BuyerParty>

Note: The actionCode element values 02 (update) and 03 (delete) cannot be used for the Contact Party node element to change a contact ID. For those changes, the contactPartyListCompleteTransmissionIndicator needs to be set. Moreover, the entire list of updated parties has to be provided, as these should replace the existing list of parties.

Example

Replace the main contact, and remove all other contacts, if existing:

  <BuyerParty contactPartyListCompleteTransmissionIndicator="true">
   <ContactParty>
    <BusinessPartnerInternalID>YZ456</BusinessPartnerInternalID>
    <MainIndicator>true</MainIndicator>
   </ContactParty>
  </BuyerParty>

Processor Party

The ProcessorParty node element contains basic information about the person working on the service request.

In the UI, the EmployeeID element corresponds to the Processor ID of the agent a ticket is assigned to.

Alternatively, the BusinessPartnerInternalID element can serve to identify the processor of the service request.

Note: If both elements are provided, the employee ID is the default value. In this case, the BusinessPartnerInternalID will be automatically determined by the system.

Example

  <ProcessorParty>
   <BusinessPartnerInternalID>15</BusinessPartnerInternalID>
  </ProcessorParty>

Service Support Team Party

The ServiceSupportTeamParty node element represents the team the service request is assigned to. The OrganisationalCentreID element specifies the ID of the organizational unit.

Example

  <ServiceSupportTeamParty>
   <OrganisationalCentreID>C007</OrganisationalCentreID><!-- ID of Support department -->
  </ServiceSupportTeamParty>

Sales Unit Party

The SalesUnitTeamParty node element represents the sales unit the service request is assigned to. The OrganisationalCentreID element specifies the ID of the organizational unit.

Example

  <SalesUnitParty>
   <OrganisationalCentreID>C42100</OrganisationalCentreID>
  </SalesUnitParty>

SalesAndServiceBusinessArea

The SalesAndServiceBusinessArea node element represents the sales and service specific business area that is valid for a service request. It can be specified by a sales organization, distribution channel and a division.

Example

  <SalesAndServiceBusinessArea>
   <SalesOrganisationID>C45000</SalesOrganisationID>
   <DistributionChannelCode>02</DistributionChannelCode>
  </SalesAndServiceBusinessArea>

Time Point Terms

Using the TimePointTerms node element, various types of time points can be specified for the service request. In the UI, the CompletionDueTimePoint element is displayed as Due Date.

The other time points are not displayed in the UI, but are used in reports.

Input is expected for the timezone and the timestamp in the following representation:

CCYY-MM-DDThh:mm:ss(.sss)Z

The part (.sss) stands for fractions of seconds, and is optional.

The time points are provided in UTC.

Example: 10 am EST with daylight saving time

<RequestInitialReceiptTimePoint timeZoneCode="EST">2011-07-28T14:00:00Z</RequestInitialReceiptTimePoint>

The following time points are available:

Time Point Qualifier	Description
Request Initial Receipt	Time point at which a request is received for the first time
Request In Process at	Time point at which a request is taken up for processing for the first time
Request Closed at	Time point at which a request is considered as finally closed
Request Finished at	Time point at which the processing of a request is completed
First Reaction Due	Time point at which an initial reaction should take place
Completion Due	Time point at which a request must be completed
Warranty Start Reference	Time point to which the begin of a warranty refers to

Note: When creating a new service request, typically the RequestInitialReceiptTimePoint element will be specified.

If the RequestInitialReceiptTimePoint is not specified, it will be set to the current timestamp.

Note: The FirstReactionDueTimePoint and CompletionDueTimePoint elements are calculated according to the service level.

When the FirstReactionDueTimePoint and CompletionDueTimePoint elements are specified, the service level assignment is deleted within the service request. The time points are taken as input from the web service. If only one of the due timepoints is specified, the other one will be set by the system.

Note: The RequestInProcessAtTimePoint, RequestClosedAtTimePoint and RequestFinishedAtTimePoint elements will be set on status changes during processing of the service request. Therefore, not all combinations of status and time points are allowed as input.

Note: All time points can be specified for data migration of completed or closed service requests.

Note: When a warranty is specified in the ServiceTerms node element, it will be considered only if the WarrantyStartReferenceTimePoint is specified, too.

When the warranty is still valid at the RequestInitialReceiptTimePoint, it will be added to the service request, and the system will automatically calculate the warranty validity period.

Duration Terms

The DurationTerms node element contains durations occurring in service request processing.

The RequestTotalProcessingDuration element contains the total duration of the processing of a service request.

RequestTotalRequestorDuration is the total duration that the requestor needs for processing a service request.

The durations are expected according to the extended representation of ISO 8601 format for time periods. The representation is as follows: PnYnMnDTnHnMnS

Example: P12Y12M2DT4H12M40S

It uses the following literals:

P = denotes the duration and must precede every duration value.

n Y = the number prefix ( n ) is the duration in years

n M = the number prefix ( n ) is the duration in months

n D = the number prefix ( n ) is the duration in days

T = is the prefix for the time period in hours, minutes, and seconds. It is not required if no times are represented.

n H = the number prefix ( n ) is the duration in hours

n M = the number prefix ( n ) is the duration in minutes

n S = the number prefix ( n ) is the duration in seconds

Time values that are not required should not be represented.

Example: P12Y1M

When hours, minutes, and/or seconds are represented, "T" must precede the time values.

Example: PT23H12M or P3Y1MT9H

Example

<DurationTerms>
<RequestTotalRequestorDuration>PT2H30M</RequestTotalRequestorDuration> 
</DurationTerms>

stands for 2 hours and 30 minutes.

Note: During service request processing in the system, both durations are calculated using status changes („RequestTotalProcessingDuration“ = „Finished At“ – „(Re-)Opened At“ + „TotalProcessingDuration (old)“, and „RequestTotalRequestorDuration“ = „Reopened At“ - „Finished At“ + „TotalRequestorDuration (old)“, respectively).

Service Terms

The ServiceTerms node element groups some elements which control the processing of the service request.

The ServicePriorityCode element can contain the following values:

Service Priority Code	Description
1	Immediate
2	Urgent
3	Normal
7	Low

The ServiceIssueCategoryID element corresponds to the Service Category in the UI. Category IDs can be chosen when maintained in the Service Category Catalog with Category Type Process.

Example

 <ServiceTerms>
   <ServicePriorityCode>3</ServicePriorityCode>
   <ServiceIssueCategoryID>CA_1</ServiceIssueCategoryID><!-- e.g. Software -->
 </ServiceTerms>

Note: The ServicePriorityCode and the ServiceIssueCategoryID elements are controlling the service level determination within the service request. Hence, they will indirectly influence the due dates. However, if the FirstReactionDueTimePoint and CompletionDueTimePoint elements are also specified in the web service, the service level determination will be overwritten by the input.

Use the WarrantyID element to explicitly specify a warranty which shall be assigned to the service request. If you do so, in addition the WarrantyStartReferenceTimePoint element in the TimePointTerms node element has to be provided. When the warranty is still valid at the RequestInitialReceiptTimePoint, it will be added to the service request, and the system will automatically calculate the warranty validity period.

If the warranty does not exist, or if it is not valid at the RequestInitialReceiptTimePoint, the system will return an error message, and the service request will not be saved.

Example

<TimePointTerms>
  <RequestInitialReceiptTimePoint timeZoneCode="CET">2010-03-28T12:00:00Z</RequestInitialReceiptTimePoint> 
 <WarrantyStartReferenceTimePoint timeZoneCode="CET">2009-12-28T12:00:00.1234567Z</WarrantyStartReferenceTimePoint>
</TimePointTerms>
<ServiceTerms>
 <WarrantyID>XW-123</WarrantyID>
</ServiceTerms>

If the last change has been performed by the customer, the ChangedByCustomerIndicator is set and the corresponding service request, recently updated by a customer, is ranked higher in the queue, compared to other service requests.

Set the ChangedByCustomerIndicator element if you want to express that the last change has been performed by the customer.

Example

<ServiceTerms>
   <ChangedByCustomerIndicator>true</ChangedByCustomerIndicator>
</ServiceTerms>

The ClassificationCode element helps to classify a service request. When created from social media activities, service requests are classified according to the result of a text analysis.

The following values are available:

Classification Code	Description
1	Problem
2	Comment
3	Not Relevant

Note: When a ticket is set to "irrelevant" on the UI, in addition, the status is set to "Closed". If you want to achieve the same behaviour using the A2X interface, set either the UserLifeCycleStatusCode or LifeCycleStatusCode element to the corresponding status value.

The UserLifeCycleStatusCode element is displayed as Status on the UI. The values and their visibility can be defined in business configuration. Values delivered by SAP are:

Status Code	Description
1	Open
2	In Process
3	Copied to CRM
4	Customer Action
5	Completed
6	Closed

Example

 <ServiceTerms>
  <UserLifeCycleStatusCode>5</UserLifeCycleStatusCode>
 </ServiceTerms>

Note: The value 6 (Closed) is currently not available in the UI.

Note: You do not have to specify the UserLifeCycleStatusCode element when a completely new service request shall be created. The status will be automatically set to its initial value as defined in the business configuration.

Note: When the user lifecycle status code is used, the system will check if the corresponding action is allowed for this service request. If not, the system will return an error message.

Note: If the UserLifeCycleStatusCode element is specified together with the LifeCycleStatusCode element, the system checks if the status combination is valid.

Main Incident Service Issue Category

The MainIncidentServiceIssueCategory node element contains the ID of the incident service issue category in the ServiceIssueCategoryID element.

Example

 <MainIncidentServiceIssueCategory>
   <ServiceIssueCategoryID>CA_1_1</ServiceIssueCategoryID><!-- e.g. UI Error Message-->
 </MainIncidentServiceIssueCategory>

Category IDs can be chosen as maintained in the Service Category Catalog with Category Type Incident.

Main Object Part Service Issue Category

The MainObjectPartServiceIssueCategory node element contains the ID of the object part service issue category in the ServiceIssueCategoryID element.

Example

  <MainObjectPartServiceIssueCategory>
   <ServiceIssueCategoryID>OBP11</ServiceIssueCategoryID>
  </MainObjectPartServiceIssueCategory>

Category IDs can be chosen as maintained in the Service Category Catalog with Category Type ObjectPart.

Main Cause Service Issue Category

The MainCauseServiceIssueCategory node element contains the ID of the cause service issue category in the ServiceIssueCategoryID element.

Example

  <MainCauseServiceIssueCategory>
   <ServiceIssueCategoryID>CAU11</ServiceIssueCategoryID>
  </MainCauseServiceIssueCategory>

Category IDs can be chosen as maintained in the Service Category Catalog with Category Type Cause.

Main Activity Service Issue Category

The MainActivityServiceIssueCategory node element contains the ID of the activity service issue category in the ServiceIssueCategoryID element.

Example

  <MainActivityServiceIssueCategory>
   <ServiceIssueCategoryID>ACT12</ServiceIssueCategoryID>
  </MainActivityServiceIssueCategory>

Category IDs can be chosen as maintained in the Service Category Catalog with Category Type Activity.

Main Service Reference Object

Using the MainServiceReferenceObject node element, the affected product can be specified for which the service request is created. It contains the MaterialID element, displayed as Product ID or Material ID in the UI.

Example

<MainServiceReferenceObject>
  <MaterialID>M1000</MaterialID>
</MainServiceReferenceObject>

Solution Proposal

The Solution Proposal node element contains information on the assigned knowledge base articles that reside in a different system.

The ID element identifies the line in the list of knowledge base articles. It cannot be externally set when creating a solution proposal. It must be used to address the line for which data shall be changed or deleted.

Note: The solution proposal ID can be accessed via the Query Service Request in the web service.

Example

Update the note of a solution proposal:

 <SolutionProposal actionCode="02">
   <ID>00163E028B301EE1B480BE673B5099DD00163E028B301EE1B480BF59DB3E59DD</ID>
   <Note>Check this article if others did not help</Note>
 </SolutionProposal>

The referenced knowledge base articles are identified using the ExternalKnowledgeBaseArticleID element. The ExternalKnowledgeBaseArticleDescription element contains its description, and the ExternalKnowledgeBaseArticleURI element identifies the web address for accessing the knowledge base article.

An additional comment can be added via the Note element.

Example

Add a solution proposal:

 <SolutionProposal actionCode="01">
   <ExternalKnowledgeBaseArticleID>1234</ExternalKnowledgeBaseArticleID>
   <ExternalKnowledgeBaseArticleDescription>Unexpected error messages after login</ExternalKnowledgeBaseArticleDescription>
   <ExternalKnowledgeBaseArticleURI>http://qwertjkl/anyURI</ExternalKnowledgeBaseArticleURI>
   <Note>Check this article if others did not help</Note>
 </SolutionProposal>

Item

The Item node element and its subelements contain detailed information, for example, on services or parts being provided to the customer.

The ID element is displayed as Line on the user interface. If the Description element is not passed, it will be filled with the description of the product entered in ProductID.

The ContractUsageRestrictionCode can be used to restrict the context in which contract items can be used for this ticket item. The possible values are defined in business configuration. When an item is created with no contract usage restriction specified, it will be filled with the contract usage restriction maintained on ticket header, if available.

Example

Create an item and restrict the list of possible contract items to maintenance, expressed by ContractUsageRestrictionCode = ZMNT:

  <Item actionCode="01">
   <ObjectNodeSenderTechnicalID>Item 10</ObjectNodeSenderTechnicalID>
   <ID>10</ID>
   <ContractUsageRestrictionCode>ZMNT</ContractUsageRestrictionCode>
   <ProductID>XCD-0442</ProductID>

Note: The list of contract items which can be assigned will now be limited to items which have no restriction, or usage restriction ZMNT maintained.

The QuantityMeasureUnitCode element applies for the RequestedQuantity as well as for the FulfilledQuantity elements. On the UI, the quantities are displayed as Planned Quantity and Actual Quantity.

The elements StartDateTime and EndDateTime within the RequestedFulfilmentPeriod node element correspond to Requested Start and Requested End in the UI; the same elements in ActualFulfilmentPeriod are named Actual Start and Actual End in the UI. For details on the expected format please refer to the Time Points section.

The ServicePerformerParty node element can be entered by using either the BusinessPartnerInternalID or the EmployeeID. On the UI, this element corresponds to the Service Technician.

Example

Create a 2 hour maintenance item for a given technician with requested dates:

  <Item actionCode="01">
   <ObjectNodeSenderTechnicalID>Item 15</ObjectNodeSenderTechnicalID>
   <ID>15</ID>
   <ProductID>XCD-0442</ProductID>
   <RequestedQuantity>2</RequestedQuantity>
   <QuantityMeasureUnitCode>HUR</QuantityMeasureUnitCode>
   <RequestedFulfilmentPeriod>
    <StartDateTime timeZoneCode="CET">2016-03-28T10:00:00Z</StartDateTime>
    <EndDateTime timeZoneCode="CET">2016-03-29T18:00:00Z</EndDateTime>
   </RequestedFulfilmentPeriod>
   <ServicePerformerParty>
    <EmployeeID>8000000492</EmployeeID>
   </ServicePerformerParty>
  <Item/>

Within the PricingTerms node element you can specifiy the WarrantyGoodwillCode element displayed as Coverage on the UI. Its values are defined in business configuration.

The BusinessTransactionDocumentReference node element enables you to specify references for the ticket item. If the BusinessSystemID is specified, the reference is considered to be an external reference, otherwise it points to a document which exists in the system.

For internal references, the following combinations are possible:

BTD Reference Type Code	BTD Relationship Role Code	BTD Reference Item Type Code
2004 (Contract)	3 (Used Document)	275 (Contract Item)
118 (Ticket)	1 (Predecessor)	271 (Service Request Item)
118 (Ticket)	2 (Successor)	271 (Service Request Item)
30 (Sales Quote)	1 (Predecessor)	30 (Sales Quote Item)
30 (Sales Quote)	2 (Successor)	30 (Sales Quote Item)
2059 (Sales Order)	1 (Predecessor)	29 (Sales Order Item)

For external references, for example the following references are possible:

BTD Reference Type Code	BTD Reference Item Type Code
29 (Invoice Request )	002 (Invoice Item)
114 (Sales Order)	28 (Sales Item)

Example

Create a reference to an item 10 of contract C181, within the same system:

  <Item actionCode="01">
   <ObjectNodeSenderTechnicalID>Item 20</ObjectNodeSenderTechnicalID>
   <ID>20</ID>
   <ProductID>XCD-0442</ProductID>
   <BusinessTransactionDocumentReference>
    <BusinessTransactionDocumentReferenceID>C181</BusinessTransactionDocumentReferenceID>
    <BusinessTransactionDocumentReferenceTypeCode>2004</BusinessTransactionDocumentReferenceTypeCode>
    <BusinessTransactionDocumentReferenceItemID>10</BusinessTransactionDocumentReferenceItemID>
    <BusinessTransactionDocumentReferenceItemTypeCode>275</BusinessTransactionDocumentReferenceItemTypeCode>
    <BusinessTransactionDocumentRelationshipRoleCode>3</BusinessTransactionDocumentRelationshipRoleCode>
   </BusinessTransactionDocumentReference>
  <Item/>

The Item Text node element can contain either an internal note (TypeCode = 10011) or customer information (TypeCode = 10024).

For more details, please refer to the Text section.

The values of the UserServiceTransactionProcessingTypeCode are defined in business configuration. They control the way in which the service transaction is processed and where the items are displayed in the UI. Customers may define their own entries in addition to the following values:

Type Code	Description
SRP0	Billing Request
SRP1	Part Consumption from Technician Stock
SRP2	Part Consumption from Consignment Stock
SRP3	Part Advance Shipment
SRP4	Part Return from Consignment Stock
SRS1	Time
SRV1	Service
EXP0	Expenses
SRCM	Complaint Item

On the UI, the element is displayed as Processing.

It can be determined automatically by the system according to the settings in business configuration (Item Processing Determination).

The ServiceRequestExecutionLifeCycleStatusCode element is named Work Progress in the UI. Possible values are:

Status Code	Description
1	Open
2	In Scheduling
3	Ready
5	Started
6	Finished
7	Not Relevant

Instead of specifying the ServiceRequestExecutionLifeCycleStatusCode directly, it is also possible to maintain a combination of the elements PlanningReleaseStatusCode, ExecutionReleaseStatusCode, and FulfilmentProcessingStatusCode, from which the work progress status is calculated. However, the recommendation is to use the ServiceRequestExecutionLifeCycleStatusCode directly.

The planning release, execution release and fulfilment processing statuses are not displayed on the UI.

Following values exist:

Planning Release Status	Description
1	Not Released
3	Deprecated
6	Not Relevant

Execution Release Status	Description
1	Not Released
3	Deprecated
6	Not Relevant

Fulfilment Processing Status	Description
1	Not Started
2	In Process
3	Finished
4	Not Relevant

The following status combinations are possible:

Planning Release Status	Execution Release Status	Fulfilment Processing Status	Service Execution Life Cycle Status
1	1	1	1
6	6	1	1
3	1	1	2
3	6	1	2
3	3	1	3
3	3	2	5
3	3	3	6
3	3	4	7
3	6	4	7
6	6	4	7

Text

Using the Text node element, communication with the customer, as well as internal information can be stored.

The ID element identifies a line in the list of texts. It cannot be externally set when creating a text. It must be used to address the line for which data shall be changed or deleted.

The different types of text are distinguished via the TypeCode element. The following values can exist:

Type Code	Description
10004	Incident Description
10007	Reply to Customer
10008	Reply from Customer
10011	Internal Comment
10072	Chat Transcript

Using the Author node element with the BusinessPartnerInternalID element, the original author of a text can be provided.

With the CreationDateTime element, the original text creation timestamp can be specified. The input format is expected in UTC in the following format:

CCYY-MM-DDThh:mm:ss(.sss)Z

The part (.sss) stands for fractions of seconds, and is optional.

The text content itself is stored as plain text in the Content element.

Note: The incident description can occur only once in one instance of a service request. All other texts can occur multiple times.

Note: All texts are language-independent.

Note: A Chat Transcript text is not changeable.

Note: The incident description can be changed only when the service request is in status Open. Therefore, also the addition textListCompleteTransmissionIndicator="true" will not work for a service request in status In Process, Closed or Completed.

Example

Add a reply to customer and change a text specified by ID:

  <Text action code="01">
   <TypeCode>10007</TypeCode>
   <CreationDateTime>2012-03-28T12:00:00Z</CreationDateTime>
   <Content>... please check the settings according to the attached article...</Content>
  </Text>
  <Text actionCode="02">
   <ID>00163E028B121ED1B2D287F8D2B9E1AA00163E028B121ED1B2D29D7C425FA1D4T00002</ID>
   <Content>... some corrected text...</Content>
  </Text>

Attachment Folder

Links or file attachments can be added or removed using the AttachmentFolder node element.

AttachmentFolder can occur only once. It can contain several attachments together with their attributes.

The UUID element of the attachment folder must be specified when changes in the list of documents shall be made.

The UUID is not visible on the UI. However, it can be retrieved using the Query Service Request In web service interface.

Note: The UUID element cannot be specified when creating an attachment folder.

Important Note

Within the AttachmentFolder node element and its subnodes, the ActionCode attributes have to be specified with a capital "A".

Example

Delete all existing attachments and replace by a new one:

  <AttachmentFolder DocumentListCompleteTransmissionIndicator="true" ActionCode="02">
   <UUID>00163E02-E0F6-1ED1-B4AE-C44BAD505361</UUID>
   <Document ActionCode="01">
     <CategoryCode>2</CategoryCode>
     <MIMECode>text/plain</MIMECode>
     <Name>attachment_test.txt</Name>
     <AlternativeName>attachment_test.txt</AlternativeName>
     <FileContent>
       <BinaryObject fileName="attachment_test.txt" mimeCode="text/plain">SW5ib3VuZCBhdHRhY2htZW50IHRlc3Q=</BinaryObject>
     </FileContent>
    </Document>
  </AttachmentFolder>

Document

The Document node element contains the attachment information.

The UUID element serves to address a specific line in the list of documents. For example, it has to be specified when a document shall be changed or deleted.

Example

Delete an attachment:

  <AttachmentFolder DocumentListCompleteTransmissionIndicator="false" ActionCode="02">
   <UUID>00163e02-e0f6-1ed1-b4ae-c44bad505361</UUID>
   <Document ActionCode="03">
     <UUID>00163e02-8b30-1ee1-b4b0-3de4b08a65d1</UUID>
   </Document>
  </AttachmentFolder>

Do not specify the following elements:

• LinkInternalIndicator

• VisibleIndicator

The values will be internally set, independent of the web service input.

The CategoryCode element indicates whether a document is a folder, link, or file:

Category Code	Description
1	File
2	Document
3	Link

In this context, values 2 (Document) and 3 (Link) can be used. Entries with category code 1 will not be displayed on the UI.

Example

  
<CategoryCode>3</CategoryCode>  

The TypeCode element can contain the following values:

Type Code	Description
10001	Standard Attachment
10068	Internal Attachment

If no document type code is specified upon creation, the system will assume a standard attachment.

Example

Add an internal attachment to an existing attachment folder:

  
  <AttachmentFolder DocumentListCompleteTransmissionIndicator="false" ActionCode="02">
   <UUID>00163E02-E0F6-1ED1-B4AE-C44BAD505361</UUID>
   <Document ActionCode="01">
     <CategoryCode>2</CategoryCode>
     <TypeCode>10068</TypeCode>
     <MIMECode>text/plain</MIMECode>
     <Name>attachment_test.txt</Name>
     <AlternativeName>attachment_test.txt</AlternativeName>
     <FileContent>
       <BinaryObject>SW5ib3VuZCBhdHRhY2htZW50IHRlc3Q=</BinaryObject>
     </FileContent>
    </Document>
  </AttachmentFolder>

Note: The document type code cannot be changed.

The Name, AlternativeName and Description elements serve to further describe the attachment. The AlternativeName element can be found as Title on the UI. The Name element is not visible on the UI. However, it is used for internal purposes, and is therefore mandatory.

Example

  
<Name>Document Name</Name>
<AlternativeName>My Document Title</AlternativeName> 

Do not specify the Property node element. It is not used.

Some elements become mandatory, dependent on the document category. They are described in the following sections.

Document with File Content

You can embed file content into the payload using the following tags:

The MIMECode element describes the medium type of the binary content according the corresponding MIME type recommendations.

Example

 <MIMECode>text/plain</MIMECode>  

Remark: The available MIME codes for attachment upload can be restricted by business configuration in the activity Allowed MIME Types for Document Upload. Usage of a MIME type that is not allowed does not become immediately visible. A service request is created. However, the attachment does not contain the data. Therefore, we recommend that you check the allowed MIME types first.

The FileContent node element contains the binary content itself in the BinaryObject element. It must be encoded in Base64 format.

The additions like mimeCode and fileName are optional.

Example

 
<FileContent>
<BinaryObject mimeCode="text/plain" fileName="test.txt">Q29uZ3JhdHVsYXRpb25zISBXaGVuIHlvdSByZWFkIHRoaXMsIHRoZSB1cGxvYWQgd2FzIHN1Y2Nlc3NmdWwu</BinaryObject>
</FileContent> 

Document as Link

Instead of file content, a link can be added. In this case, the ExternalLinkWebURI element must be provided.

Example

  
<ExternalLinkWebURI>http://qwertjkl/anyURI</ExternalLinkWebURI>  

Example XML for attachments

The first document references a URL, the second contains a plain text file content.

  <AttachmentFolder ActionCode="01">
   <Document ActionCode="01">
    <CategoryCode>3</CategoryCode>
    <Name>link name</Name>
    <AlternativeName>link title</AlternativeName>
    <Description languageCode="EN">link comment</Description>
    <ExternalLinkWebURI>http://qwertjkl/anyURI</ExternalLinkWebURI>
   </Document>
   <Document ActionCode="01">
    <CategoryCode>2</CategoryCode>
    <MIMECode>text/plain</MIMECode>
    <Name>test.txt</Name>
    <AlternativeName>test file</AlternativeName>
    <Description languageCode="EN">My comment for the test file</Description>
    <FileContent>
    <BinaryObject>Q29uZ3JhdHVsYXRpb25zISBXaGVuIHlvdSByZWFkIHRoaXMsIHRoZSB1cGxvYWQgd2FzIHN1Y2Nlc3NmdWwu</BinaryObject>
  </FileContent>
 </Document>
</AttachmentFolder> 

Usage

This operation is used to migrate service requests from an external system.

 Show full documentation

 Show full documentation

Definition

To check if service request data can be created or updated without errors.

Business Context and Use

The web service request and response message types of the CheckMaintainBundle operation are the same as those of the MaintainBundle operation.

The explanations given can therefore also be applied to the CheckMaintainBundle operation.