Drag and drop the code snippets to create a valid AXL API <addUCService> request. Not all options are used.

Question

Exhibits

Explanation

The options field in your question is empty ({}), so no code snippets were provided. I'll explain the <addUCService> AXL API request from first principles so you can apply the knowledge regardless of which snippets appear on the actual exam.

Overview: What is <addUCService>?

The Cisco AXL (Administrative XML) API is a SOAP-based web service used to programmatically configure Cisco Unified Communications Manager (CUCM). The <addUCService> operation creates a UC Service - a reusable pointer to a UC resource (like Voicemail, IM & Presence, CTI, etc.) that can be assigned to a Service Profile and then provisioned to phones/users.

Valid Request Structure

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns="http://www.cisco.com/AXL/API/14.0">
  <soapenv:Header/>
  <soapenv:Body>
    <ns:addUCService>
      <ucService>
        <name>MyVoicemailService</name>
        <serviceType>Voicemail</serviceType>
        <hostnameorip>192.168.1.50</hostnameorip>
        <port>443</port>
        <protocol>HTTPS</protocol>
      </ucService>
    </ns:addUCService>
  </soapenv:Body>
</soapenv:Envelope>

Step-by-Step Explanation

1. SOAP Envelope + Namespace Declaration

<soapenv:Envelope
    xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
    xmlns:ns="http://www.cisco.com/AXL/API/14.0">

Why: AXL uses SOAP over HTTPS. The soapenv namespace wraps the message per the SOAP 1.1 spec. The ns namespace must match your CUCM version (e.g., 14.0, 12.5). A mismatch causes a schema validation error or silent failure.

If skipped: The server cannot parse the request - it won't know this is an AXL call.

2. Empty <soapenv:Header/>

Why: SOAP requires a Header element even when unused. Authentication in AXL is handled via HTTP Basic Auth headers at the transport layer, not inside the SOAP header.

If skipped: Malformed SOAP envelope - likely a parse error.

3. <soapenv:Body> wrapping <ns:addUCService>

Why: The Body contains the actual operation. The operation element must be namespace-prefixed (ns:addUCService) to bind it to the AXL schema.

If skipped or un-prefixed: CUCM returns a fault - operation not recognized.

4. <ucService> container

Why: AXL wraps the object being created in a typed element. This is the data transfer object (DTO) pattern AXL uses consistently across all add* operations.

If skipped: Schema violation - the server expects a child element named ucService.

5. Required fields inside <ucService>

If serviceType is wrong or missing: CUCM either rejects the request or creates a mis-typed service that won't work with service profiles.

What Would Go Wrong Out of Order

• Namespace before operation name is mandatory - you can't reference ns:addUCService without first declaring xmlns:ns.
• <ucService> before its children - XML is document-order dependent; children must be nested, not siblings.
• Body before Header - violates SOAP spec ordering; some parsers are strict about this.

Memory Tip

Think of AXL requests as a Russian nesting doll:

Envelope
  └─ Header (empty, but required)
  └─ Body
       └─ Operation (ns:addUCService)
            └─ Object (ucService)
                 └─ Fields (name, serviceType, host, port, protocol)

Every AXL add* call follows this same pattern - only the operation name and field names change.

If you can share the actual code snippet options from the question, I can give you a precise drag-and-drop ordering.

No community discussion yet for this question.