Reliably determining Mandatory attributes for AddX AXL Call

[Jonathan Els]

Hi,

Does anyone know a way to reliably determine what are the minimum attributes needed for an AXL call from the xsd?  I want to do this programmatically.

For example, for XPhone, which is specified for addPhoneReq, I need to filter from the 120+ attrs to get the following mandatory ones:

{  

    'class': None,

    'commonPhoneConfigName': None,

    'devicePoolName': None,

    'locationName': None,

    'name': None,

    'product': None,

    'protocol': None

}

I can't seem to find a reliable set of element attributes to determine this from.  I'm currently considering:

• nillable
• default
• is optional
• minOccurs

The best that I seem to get is making sure that minOccurs is >=1, that an attr is not optional, does not have a defined default, and is not nillable.   Seems sensible enough to me.

Apply the above, we filter down to the following for XPhone:

{  

    'class': None,

    'commonPhoneConfigName': None,

    'locationName': None,

    'name': None,

    'product': None,

    'protocol': None

}

That's because this is defined:

<xsd:element maxOccurs="1" minOccurs="1" name="devicePoolName" nillable="true" type="axlapi:XFkType"/>

Send this to AXL in an addPhone, and it barks on a missing devicePoolName...

I have tried other permutations, and either get too many, or too few.  Seems that I'm on a fool's errand here.  Is it possible, or do I need to maintain this statically in a data model?

[stephan.steiner]

They might have different schemas... I'm just looking at the downloadable one which has devicePool as a non dashed element meaning it is required. Back on the olden days when I started with AXL (version 4 of CUCM), you couldn't even autogenerate classes from the schema files so I started my own class library that implements the schema as per the documentation Cisco publishes.. throwing exceptions when you try to pass something that was marked mandatory in the documentation. So far that hasn't let me down. But adding new objects / extending objects for every release isn't exactly my favorite job either.

The doc also has locationName, useTrustedRelayPoint, phoneTemplateName and some others as mandatory. Some might be conditionally mandatory though since a device can be a lot of things.

Most of the time, I grab an existing device or device template as basis for creating a new device, so I don't run into this problem. That's not to say I'm not longing for an operation that would create a device based on a template where I just have to provide the values I want to change (so then it would be version independent even with my manual class generation approach).

[Jonathan Els]

I've given up for now, and am storing this in data models.  Found a lot of cases where mandatories are not mandatory, or where I get barked at by non-mandatories.  locationName is a common one - often assigns Hub_None if you don't pass it anything.  Seen this for a lot of add methods.

I'm using Python's zeep library, which does schema validation and model generation very well.  It's handling is pretty robust across versions, but as its interpreted you pay up front when the script runs.  My only problem lies in the xsd definitions themselves, and the various places where the API implementation doesn't honour the agreement.  Generally, these don't change between AXL versions.

I'm not a developer, just a lowly UC engineer, so my question may be limited by my lack of knowledge of the SOAP protocol and xsd documents.  If anyone can advise how to determine mandatory params from the xsd, I'd really appreciate that.