NET -> XI -> WAS Scenario: elementFormDefault="qualified" SUPPORTED???

[szymon_bolek]

Hello Gurus,

I've been looking and looking and have found nothing:(

I have the following scenario:

.NET <-> XI <-> WAS

In the XI I have created the XSDs-> Messages -> Interfaces and then generated WSDL and Proxies in the WAS. In the XSDs no attribute 'elementFormDefault' was set, means per default elementFormDefault="ungualified".

I generated the XML Messages and tested it with JMeter or other Tool, just to make sure the XI -> WAS works.

Than I gave the WSDLs to .NET guys. They changed the elementFormDefault to "qualified" in order to create client proxy classes correctly(so they say). Then they called XI Services and boom, nothing worked. The messages they generate are different that these we generated, because of this attribute elementFormDefault set to "qualified".

My general question is, is it supported at all, this attribute elementFormDefault="qualified"??

I tried later to upload an XSD file to XI with this attribute set, but the Editor said, that this is erroneus and would not accept it. So for me this is not supported, but I have found a document, an excel file

https://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/2089f29b-b10a-2a10-5297-e258df0c...

and it says, that Editor is not supported, but Java and ABAP Proxies are supported. Are these client or server proxies? Because for me it's not consistent, to say editor does not support it and proxies do.

I would appreciate every help and hints.

Maybe there is some way for .NET to work it around, or maybe for XI to tell the WSDLs and generated proxies to use qualified.

Systems that we use:

.NET: MS .NET Framework v3.0 und + Windows Communication Framework (WCF)

XI: Netweaver 04 640 SP18

WAS: SAP NetWeaver 2004s Rel 7.0 SP10

best regards

Simon

[henrique_pinto]

> Than I gave the WSDLs to .NET guys. They changed the elementFormDefault to "qualified" in order to create client proxy classes correctly(so they say).

This is your problem.

By definition, the consumer of a service cannot change the wsdl at all! The WSDL is the description of the service interface, and if they change it, it's nothing but expected that the message will error out.

You can do 2 things:

1. tell the .NET guys to use the definition you've created, because there's nothing wrong about using unqualified elementFormDefault (it only defines the namespaces of inner tags, but the applications should understand it anyway);

2. if you really wanna be complacent with them, you can use elementFormDefault = qualified in your external definition, there is no problem at all. Just change the xsd locally (for example, in notepad or XMLSpy) and reimport it to the external definition. But be aware that you'll have to redefine all mappings and regenerate all proxies related to this service interface.

Regards,

Henrique.

[szymon_bolek]

Hello,

Thanks for the answers.

>

> You can do 2 things:
> 1. tell the .NET guys to use the definition you've created, because there's nothing wrong about using unqualified elementFormDefault (it only defines the namespaces of inner tags, but the applications should understand it anyway);

That is true, there is nothing with my WSDLs;) Per default it's unqualified.

But ...

> 2. if you really wanna be complacent with them, you can use elementFormDefault = qualified in your external definition, there is no problem at all. Just change the xsd locally (for example, in notepad or XMLSpy) and reimport it to the external definition. But be aware that you'll have to redefine all mappings and regenerate all proxies related to this service interface.

You write, that there is no problem with importing XSDs with elementFormDefault="qualified".

I cannot agree with this, because when I try to do so:

XML Spy change -> reimport to XI

it says to me, that there is an error with (elementFormDefault="qualified"):

Schema to be edited defines qualified element names (elementFormDefault = 'qualified')

and won't re-import the file. The issue with regenerationg mappings and proxies etc, that is plain clear, and pain in the neck, that is why I would like to avoid it, and first get cleared if this attribute is supported.

It seems, from your message, that it indeed is supported, but I haven't found the way to make it work.

Still need help.

best regards

Simon:)

[henrique_pinto]

Hi Simon,

I've successfully used both cases (unqualified and qualified) for external definitions in SAP PI 7.0 SP9+ and creating proxies in WAS 7.00 SP9+.

I've never tried to do it in XI 3.0, but I think it should also be possible.

Do you have access to a PI 7.0 system just for testing this?

Regards,

Henrique.

[szymon_bolek]

>

> Hi Simon,
> 
> I've successfully used both cases (unqualified and qualified) for external definitions in SAP PI 7.0 SP9+ and creating proxies in WAS 7.00 SP9+.
> 
> I've never tried to do it in XI 3.0, but I think it should also be possible.
> 
> Do you have access to a PI 7.0 system just for testing this?
> 
> Regards,
> Henrique.

Hi:) thanks for reply

No unfortunately I don't have PI 7.0.

Main problem that I have, I cannot import XSD files into XI with this attribute set to qualified.

I have already opened an OSS Ticket in SAP for this one, but haven't get any reply yet.

I still hope there is someone out there to answer this question.

But I guess this attribute is in fact not supported in XI. I will still keep this post open, hoping somene will prove me wrong, or confirm it's indeed not supported!?

best regards

Simon:)

[henrique_pinto]

Hi Simon,

if it's just the importing as external definition, I can also guarantee that it can be done in XI 3.0 also. I'm not sure about proxy generation for WAS 640, though.

Maybe there's something else wrong with the .xsd. Could you post it here?

Henrique.

[szymon_bolek]

>

> Hi Simon,
> 
> if it's just the importing as external definition, I can also guarantee that it can be done in XI 3.0 also. I'm not sure about proxy generation for WAS 640, though.
> 
> Maybe there's something else wrong with the .xsd. Could you post it here?
> 
> Henrique.

Hello:)

here is the XSD file: short, simple and with qualified:)

<?xml version="1.0" encoding="UTF-8"?>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://www.evosoft.com/xi/dotnet3/00" targetNamespace="http://www.evosoft.com/xi/dotnet3/00" elementFormDefault="qualified">
	<xsd:complexType name="Test_DT">
		<xsd:annotation>
			<xsd:appinfo source="http://sap.com/xi/TextID">28e5c9b0ee7311dca83000114337b1b5</xsd:appinfo>
		</xsd:annotation>
		<xsd:sequence>
			<xsd:element name="Text" type="xsd:string">
				<xsd:annotation>
					<xsd:appinfo source="http://sap.com/xi/TextID">3ea75f20a3fa11dc8144ddc60a01ca16</xsd:appinfo>
				</xsd:annotation>
			</xsd:element>
		</xsd:sequence>
	</xsd:complexType>
</xsd:schema>

It won't import:(

Give it a shot, maybe there is something wrong with it, but i doubt it.

best regards

simon:)

[henrique_pinto]

Hi Simon,

the problem with this XSD is that it has no root element.

It only defines a complex type. It would be ok for a reference XSD (if some other XSD imports it), but it does not make sense as a whole.

Just add the following line just before the complex type definition:

> <xsd:element name="Test_DT" type="Test_DT"/>

However, this problem alone should not be a problem for importing in XI. I don't have any 3.0 system here, but I've imported it successfully in 7.0. Maybe there's something wrong with your system?

Regards,

Henrique.

[szymon_bolek]

>

> Hi Simon,
> 
> the problem with this XSD is that it has no root element.
> It only defines a complex type. It would be ok for a reference XSD (if some other XSD imports it), but it does not make sense as a whole.
> 
> Just add the following line just before the complex type definition:
> 
> > <xsd:element name="Test_DT" type="Test_DT"/>
> 
> However, this problem alone should not be a problem for importing in XI. I don't have any 3.0 system here, but I've imported it successfully in 7.0. Maybe there's something wrong with your system?
> 
> Regards,
> Henrique.

Hello Henrique,

Tried it <xsd:element name="Test_DT" type="Test_DT"/> out. There is a warning for this, which says it will be ignored. And still there is an error as far as qualified is concerned.

I do not think so, there is a problem in XI, unless these 3 Systems I tried it on are set-up wrong.

regards

simon:)

[henrique_pinto]

Hi Simon,

I've tried to import the XSD as is, and it worked ok (external definition type = XSD).

Could you paste the whole WSDL, so I can try to import it too?

Regards,

Henrique.

[szymon_bolek]

>

> Hi Simon,
> 
> I've tried to import the XSD as is, and it worked ok (external definition type = XSD).
> 
> Could you paste the whole WSDL, so I can try to import it too?
> 
> Regards,
> Henrique.

Hi Henrique,

Sorry for not responding so long. I will paste the WSDL here, so far I haven't got time:( I will manage to do this tomorrow evening.

regards

Simon

[Former Member]

Hi Simon,

Did you manage to solve this? I'm running into the same issue (also on XI, not PI).

In my case the XSD's are delivered to me. Importing the XSD's as external definitions is no problem, but they contain xsd imports.

As soon as I try to use any message type (xsd element) defined in the XSD's in a Message Interface, the Context Objects tab fails to resolve the complex/simpletypes defined in the xsd imports.

I'm able to work around this by defining each type as a separate Data Type, but... I cannot import the XSD that defines the type into the datatype, because XI then complains about the elementFormDefault="qualified" attribute in the XSD.

I can of course modify the XSD's (doing the opposite thing your .NET counterparts did), but then XI will probably produce XML that does not comply with the original XSD's.

Any ideas?

Kind regards,

Pascal

[szymon_bolek]

Sorry Pascal, did not see you question. No not really, no definite resolution back then.

.NET guys changed their 'strategy' and we did not have the problems anymore, but the actual question was not answered, no.

best

regards

simon:)

[Former Member]

hi simon,

when we work with wsdl's we should be careful in monitoring WSDL file.

WSDL is a web standard sometimes its not acceptable by thrid party's.

want to share my experience in giving wsdl file to .net.

if u import RFC and publish RFC as wsdl,it wont work in .net or any other service reason namespace in rfc wsdl will be starting with URN:
but any other framework will expect http:

so for this we created message types explicitly instead of using RFC as message type.

in your case you are trying to edit wsdl published by XI and if schema is not consitent between systems it will through error and XI wont support schema which is not in expected format.

when u publish services from peoplesoft application u find difficulty in importing in to XI.

coming to proxies

proxies are classes(jar and abap objects) created for interfaces,and

WSDL is XML representation giving info regarding location of interface service.

importing classes and importing XML document is incomparabale.

classes can be edited as decompiler required but XML can be edited with in no time.

dont worry about XML qualification,just give the WSDL and see namesapces start with http:
as URN is not applicable for third party.

and proxies will work withou any issue.

we integarted .NET with ABAP proxies.

Thanks & Regards,

Rama Krishna