Error messages

 

Error Message: soap_serve - Caught XML API exception scxmlapi(19) - Doc Engine call failed with cc -1

Service Management publisher:

This error message is issued either when the Document Engine did not attempt to write the record, because the Process called via extaccess does not perform a save operation, or if a validation failed and the save could not be performed. To fix this issue, ensure that the Process called does perform an action that adds or updates a database record. If it does, add the msglog:1 parameter to the sm.ini and rerun the Web Service. Check the sm.log file for any validation error messages and then either pass the required information or change the extaccess record to add any missing required fields to it. If your are still unsure what is the root cause of the issue after this, add RTM:3 and debugdbquery:999 to the sm.ini and retest the Web service operation. If your are still unsure what is the root cause of the issue after this, add RTM:3 and debugdbquery:999 to the sm.ini file and retest the Web service operation.

 

Error Message: Invalid or missing file name in XML request

Service Management publisher or consumer:

Complete Error Message: <SOAP-ENV:Fault><faultcode>SOAP-ENV:Server</faultcode><faultstring>scxmlapi(16) - Invalid or missing file name in XML request</faultstring><detail><appFaultCode>16</appFaultCode><appFaultString>scxmlapi(16) - Invalid or missing file name in XML request</appFaultString></detail></SOAP-ENV:Fault>

This error message is issued if the binaries cannot successfully retrieve the name for the Object to access from the extaccess file. This issue occurs most often when the Object name is in “CamelCase” notation. To prevent this issue, do not use “CamelCase” notation (where the name contains compound words or phrases that are joined without spaces, and each word is capitalized within the name.) in the Object Name in the extaccess file. As a best practice, use the name of the dbdicts as the Object Name as well.

If the underlying cause is not the camel case notation, you can modify the SOAP body by adding filename=”<filename>” to work around this issue. For example:

<soap:Body>

<CreateProblemRequest filename="rootcause"

xmlns="http://<server>:<port>/SM/7">

 

Error Message: getType() in com.peregrine.webservice.ComputerInstanceTypeDevice cannot override getType() in com.peregrine.webservice.common.StructureType; attempting to use incompatible return type

 

The ConfigurationManagement WSDL is made up of the device extaccess record in addition to a number of device attribute files (such as computer). The following errors occur when you set the API Caption for the type field in the device extaccess record to “type” or “Type” and then attempt to compile the WSDL using Apache Ant:

			
build_java:
    [javac] Compiling 114 source files to C:\Service 
Manager\server\webservices\sample\AxisSample\build
    [javac] C:\Service 
Manager\server\webservices\sample\AxisSample\src\com\
peregrine\webservice\ComputerInstanceTypeDevice.java:225: getType() in 
com.peregrine.webservice.ComputerInstanceTypeDevice cannot override 
getType() in com.peregrine.webservice.common.StructureType; attempting to 
use incompatible return type
    [javac] found   : com.peregrine.webservice.common.StringType
    [javac] required: java.lang.String
    [javac]     public com.peregrine.webservice.common.StringType 
    getType() {
    [javac]
    [javac] 1 error

BUILD FAILED
C:\Service Manager\server\webservices\sample\AxisSample\
build.xml:184: Compile
 failed; see the compiler error output for details.

To avoid this or similar errors, make sure that the name is valid and does not conflict with previously defined names when you set up alias names (“API Captions”). All of the common.xsd definitions for data types such as StructureType, ArrayType, have a type attribute, for which Axis manufactures a getType Java method. When it generates a getType method for this new type property/field, those two methods conflict. It does not matter whether you specify “type” or “Type” because Axis uses camel-case naming conventions for its generated method names. Whenever an API caption can cause a conflict with a pre-existing function, change it to be something unique; in this case, for example, make the API caption CIType.