Проблема WSDL-Axis2 CodeGen

У меня проблема с отправкой запроса WS на сервер. Похоже, что пространство имен (NS) в одном из сложных типов операций приводит к тому, что xsi:type извергается как часть сгенерированного запроса SOAP.

См. ниже пример WSDL:

<xs:complexType name="SubscribeAppendantProductRequest">
<xs:complexContent>
<xs:extension base="business:Common">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Product">
<xs:complexType>
<xs:complexContent>
<xs:extension base="business:Product">
<xs:sequence>
<xs:element maxOccurs="unbounded" minOccurs="0" name="Service" type="business:Service" />
<xs:element minOccurs="0" name="EffectiveDate" type="xs:string" />
<xs:element minOccurs="0" name="ExpireDate" type="xs:string" />
<xs:element name="ValidMode" type="business:ValidMode" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="HandlingChargeFlag" type="xs:int" />
<xs:element minOccurs="0" name="CustID" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

См. ниже код, генерирующий запрос на операцию/заглушку Axis2:

SubscribeAppendantProductRequest sub_req = new SubscribeAppendantProductRequest();
Product_type2 subscribedToProduct = new Product_type2();
subscribedToProduct.setId(productKey);
subscribedToProduct.setValidMode(ValidMode.value1);
Product_type2 []subscribedProductList = new Product_type2[1];
subscribedProductList[0]=subscribedToProduct;
sub_req.addProduct(subscribedToProduct);
sub_req.setProduct(subscribedProductList);
sub_req.setSubscriberNo(subscriber);
return sub_req;

Каждый раз, когда я отправляю запрос, я получаю следующее сообщение об ошибке:

Ошибка параметра интерфейса: имеется 1 ошибка проверки XML: неверный xsi:type qname: 'ns2:Product_type2' в элементе SubscribeAppendantProductRequest

См. ниже сгенерированный SOAP-запрос:

<?xml version='1.0' encoding='UTF-8'?>
<soapenv:Envelope xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
<soapenv:Body>
<ns3:SubscribeAppendantProductRequestMsg xmlns:ns3="http://www.huawei.com/bme/cbsinterface/cbs/businessmgrmsg">
<RequestHeader>
<ns1:CommandId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">SubscribeAppendantProduct</ns1:CommandId>
<ns1:Version xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">1.0</ns1:Version>
<ns1:TransactionId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">trans001</ns1:TransactionId>
<ns1:SequenceId xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">2002396871686</ns1:SequenceId>
<ns1:RequestType xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">Event</ns1:RequestType>
<ns1:SerialNo xmlns:ns1="http://www.huawei.com/bme/cbsinterface/common">2002396871686</ns1:SerialNo>
</RequestHeader>
<SubscribeAppendantProductRequest xmlns:ns2="http://www.huawei.com/bme/cbsinterface/cbs/businessmgr" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="ns2:SubscribeAppendantProductRequest">
<ns2:SubscriberNo>8090547759</ns2:SubscriberNo>
<ns2:Product xsi:type="ns2:Product_type2">
<ns2:Id>121390</ns2:Id>
<ns2:ValidMode>4050000</ns2:ValidMode>
</ns2:Product>
</SubscribeAppendantProductRequest>
</ns3:SubscribeAppendantProductRequestMsg>
</soapenv:Body>
</soapenv:Envelope>

Я считаю, что проблема связана с базовым расширением сложного типа Product.

Как ни странно, я запускал аналогичную программу на другом типе операций с аналогичными характеристиками, и все работало нормально. См. ниже пример функциональной операции WSDL:

<xs:complexType name="UnSubscribeAppendantProductRequest">
<xs:complexContent>
<xs:extension base="business:Common">
<xs:sequence>
<xs:element maxOccurs="unbounded" name="Product">
<xs:complexType>
<xs:sequence>
<xs:element name="ProductID" type="xs:string" />
<xs:element minOccurs="0" name="ProductOrderKey" type="xs:string" />
<xs:element name="ValidMode" type="xs:string" />
<xs:element minOccurs="0" name="ExpireDate" type="xs:string" />
<xs:element maxOccurs="unbounded" minOccurs="0" name="Service">
<xs:complexType>
<xs:sequence>
<xs:element name="Id" type="xs:string" />
<xs:element maxOccurs="unbounded" name="SimpleProperty" type="business:SimpleProperty" />
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element minOccurs="0" name="CustID" type="xs:string" />
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>

Когда я сделал сравнение, кажется, что они оба используют сложный тип Product, но кажется, что неисправный использует сложный тип Product в качестве расширения.

У кого-нибудь есть опыт в этом? Любые возможные решения? Было бы все иначе, если бы я использовал другую привязку данных (то есть из ADB)?


person Kris Ogirri    schedule 12.08.2010    source источник


Ответы (1)


В конце концов я решил использовать формат привязки данных xmlbeans для классов Outputted Generated Java, представляющих операции WSDL.

Похоже, что привязка данных Axis2 (ADB) не обрабатывает WSDL с несколькими сложными типами (которые при переводе в код Java возвращают объекты Java), особенно если они настроены с атрибутами XMLSchema maxOccurs='unbounded' .

Когда выходные данные генерируются при использовании ADB, кажется, что отдельный Object_x (где x — целое число в диапазоне от 1 до n) создается для каждого сложного типа, называемого объектом, для которого потребуются разные свойства в зависимости от требований к операции, как определено в WSDL. документ. Object_x будет помещен в тот же пакет, что и другие объекты, сгенерированные wsdl2java. Затем отправленный запрос SOAP содержит атрибут type=Object_x XSD, сопровождающий преобразование объекта в запрос SOAP, как показано в исходном вопросе.

Когда вывод генерируется при использовании xmlbeans, wsdl2java генерирует класс package.Object, где package — это имя операции, а Object — сложный тип, и кажется, что xmlbeans игнорирует атрибут maxOccurs='unbounded', а отправленный запрос SOAP не учитывается. иметь какие-либо параметры типа, помещенные в него.

Ну вот как я решил эту проблему. Я отправил отчет об ошибке команде разработчиков Axis2, но я буду следить за ним, чтобы увидеть, есть ли какие-либо решения в будущих версиях.

Спасибо всем, кто пытался.

person Kris Ogirri    schedule 01.09.2010