Show full documentation

 Show full documentation

Definition

An interface to manage warranty data from an external system.

Business Context and Use

This web service is used to maintain warranties 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 warranty. The CheckMaintainBundle operation is used to check if the one or more instances of the warranty can be maintained.

The signatures of the two operations are identical.

Example

The following example creates a warranty with duration of 2 years and activates it immediately:

<n0:WarrantyBundleMaintainRequest_sync xmlns:n0="http://sap.com/xi/SAPGlobal20/Global">
 <BasicMessageHeader>
  <ID>00163E0290581ED28B972C9E3289459O</ID>
 </BasicMessageHeader>
 <Warranty actionCode="01">
  <InternalID>XYZ98765</InternalID>
  <ServiceProcessUsabilityLifeCycleStatusCode>2       </ServiceProcessUsabilityLifeCycleStatusCode>
  <Duration>P2Y</Duration>
  <Description actionCode="01">
   <Description languageCode="EN">2 Year Standard Warranty</Description>
  </Description>
 </Warranty>
</n0:WarrantyBundleMaintainRequest_sync>

Prerequisites

Technical Prerequisites:

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

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:

• Service issue categories

More Information

General Information

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

 Show full documentation

 Show full documentation

Definition

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

Business Context and Use

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

The request message of the operation MaintainBundle contains a BasicMessageHeader node element, as well as a Warranty node element containing the warranty data to be created or updated. The detailed structure of the warranty node will be explained in the following sub-chapters. The warranty node can occur multiple times in the request message, meaning that multiple warranties 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 warranty-specific node with ReferenceObjectNodeSenderTechnicalID, ChangeStateID; as well as internal ID.

Structure

Warranty

The Warranty node element contains basic information about the warranty such as internal ID, duration and status.

These fields can be found in the list of warranties in the products work center, or they will appear when creating a new warranty.

Example

Create a warranty with minimal data:

 <Warranty actionCode="01">
  <InternalID>XYZ98765</InternalID>
  <ServiceProcessUsabilityLifeCycleStatusCode>2</ServiceProcessUsabilityLifeCycleStatusCode>
  <Duration>P2Y</Duration>
 </Warranty>

The service process usability lifecycle status code can occur with the following values:

Status Code	Description
1	In Preparation
2	Active
3	Blocked

Only active warranties can be used, for example, in service requests (tickets).

Note: When creating a new warranty, the default value of the lifecycle status code is 1.

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

Service Issue Category Coverage

Service issue categories can be specified that are not covered by the warranty.

Note: Hereby also all sub categories of the specified service issue category are not covered.

Note: During determination of warranty in a service request (ticket), the warranty is only determined in case the corresponding service issue category is not excluded from the warranty.

Example

Service Issue Category X14175 "Customer Fault" is not covered by the warranty.

  <ServiceIssueCategoryCoverage actionCode="01">
   <ServiceIssueCategoryID>X14175</ServiceIssueCategoryID>
   <CoveredIndicator>false</CoveredIndicator>
  </ServiceIssueCategoryCoverage>

Description

The warranty description can be maintained in several languages. Therefore, the Description node element can be specified multiple times.

Note: Per language, only one description can be maintained.

Example

Edit an English and a Spanish description:

  <Description actionCode="04">
   <Description languageCode="EN">English description</Description>
  </Description>
  <Description actionCode="04">
   <Description languageCode="ES">Descripción española</Description>
  </Description>

Detailed Description

The Text element of the Detailed Description node element is displayed as Notes in the UI.

Since it can occur in several languages, the Detailed Description node element can be specified multiple times.

Note: Per language, only one detailed description can be maintained.

Example

Create an English description, delete the German one:

<DetailedDescription actionCode="01">
  <Text languageCode="EN">English detailed description</Text>
</DetailedDescription>
<DetailedDescription actionCode="03">
  <Text languageCode="DE"></Text>
</DetailedDescription>

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

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>10001</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 warranty 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> 

 Show full documentation

 Show full documentation

Definition

To check if warranty 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.