|
Home > Archive > BizTalk Server General > June 2006 > ns0 once again!!! Is there a consensus now?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
ns0 once again!!! Is there a consensus now?
|
|
| BizTalk Benjamin 2006-06-24, 7:15 pm |
| Hi... another post from lil ol me,
Just a quick clarification. It appears that standard .NET library to
serialise objects and send to a Biztalk webservice is not sufficient to do
the job since we cannot prefix the root element with ns0. [We can specify a
target namespace and prefix, but cannot actually produce something with a
qualified root element].
So the option we have is to either put in a hack where we do some string
functions to place the ns0 or we have a separate message without any
targetnamespaces in Biztalk so we can submit the data, and then map it to
stronger qualified messages inside the orchestrations.
Does anyone know of other techniques? I came across an old post on this
technique from July last year (including my own comments on the same) but
there didnt seem to be any universal consensus.
I do remember the Biztalk mapper throwing weird script errors everytime we
tried to open a map where one of the messages had no targetNamespace. Is that
a known issue or would it have been just some environment bug. Maybe we can
opt for custom XSLT if it is a known issue.
Thoughts from the gurus?
Benjy
| |
| Tomas Restrepo \(MVP\) 2006-06-24, 7:15 pm |
| Benjamin,
>
> Just a quick clarification. It appears that standard .NET library to
> serialise objects and send to a Biztalk webservice is not sufficient to do
> the job since we cannot prefix the root element with ns0. [We can specify
> a
> target namespace and prefix, but cannot actually produce something with a
> qualified root element].
I've never had an issue with this, and the .NET libraries do fully support
XML namespaces. Mind you, you do not need to get the root element prefixed
with ns0, all you require is that the element is in the correct namespace
(the prefix itself is irrelevant and is only used to alias a namespace, and
it's not necessary if you're using xmlns='' to specify a default namespace).
> So the option we have is to either put in a hack where we do some string
> functions to place the ns0 or we have a separate message without any
> targetnamespaces in Biztalk so we can submit the data, and then map it to
> stronger qualified messages inside the orchestrations.
Don't see why you'd need to do this unless you're doing something wrong.
Usually, the .NET WebService proxy generation tool works just fine and deals
just fine with namespaces. Perhaps you're defining your webservice in such a
way that you're generating an incorrect service description?
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
|
|
"BizTalk Benjamin" <BizTalkBenjamin@discussions.microsoft.com> wrote in
message news:F69A2A7E-5AA9-4026-9C24-5B6768B0AC8F@microsoft.com...
Benjy-
I'm not clear what the problem is here, or even that you have one. <ns0:Root
xmlns:ns0="blablabla" is functionally equivialent to: <Root
xmlns="blablabla". Maybe I'm not understanding what you're asking but it
shouldn't matter what namespace prefix you use for the document element...
Paul Brinkley-Rogers
> Hi... another post from lil ol me,
>
> Just a quick clarification. It appears that standard .NET library to
> serialise objects and send to a Biztalk webservice is not sufficient to do
> the job since we cannot prefix the root element with ns0. [We can specify
> a
> target namespace and prefix, but cannot actually produce something with a
> qualified root element].
>
> So the option we have is to either put in a hack where we do some string
> functions to place the ns0 or we have a separate message without any
> targetnamespaces in Biztalk so we can submit the data, and then map it to
> stronger qualified messages inside the orchestrations.
>
> Does anyone know of other techniques? I came across an old post on this
> technique from July last year (including my own comments on the same) but
> there didnt seem to be any universal consensus.
>
> I do remember the Biztalk mapper throwing weird script errors everytime we
> tried to open a map where one of the messages had no targetNamespace. Is
> that
> a known issue or would it have been just some environment bug. Maybe we
> can
> opt for custom XSLT if it is a known issue.
>
> Thoughts from the gurus?
>
> Benjy
>
>
>
| |
| BizTalk Benjamin 2006-06-25, 1:17 pm |
| Paul,
You are right , they are functionally equivalent , BUT biztalk throws errors
when i validate the message without any ns0 against the schema. It says it
cannot find the definition for any of the elements. The error messages go
away only when i set ns0 prefix on the root element and for the namespace.
Benjy
"PBR" wrote:
[vbcol=seagreen]
>
> "BizTalk Benjamin" <BizTalkBenjamin@discussions.microsoft.com> wrote in
> message news:F69A2A7E-5AA9-4026-9C24-5B6768B0AC8F@microsoft.com...
> Benjy-
>
> I'm not clear what the problem is here, or even that you have one. <ns0:Root
> xmlns:ns0="blablabla" is functionally equivialent to: <Root
> xmlns="blablabla". Maybe I'm not understanding what you're asking but it
> shouldn't matter what namespace prefix you use for the document element...
>
>
> Paul Brinkley-Rogers
>
| |
| BizTalk Benjamin 2006-06-25, 1:17 pm |
| Tomas,
Without the ns0 prefix for the root element biztalk throws errors for every
single element in my file. I have to manually prefix with ns0 to get through
the validation. I'll try to explain
A sample of the file i first got from the .NET component was
<CustomerData xmlns="targetnamespace">
<fname> </fname>
<lname> </lname>
</CustomerData>
This file failed the validation. I then prefixed just the namespace with ns0
and it failed again (Which was to be expected) . So i then manually prefixed
ns0 in front of CustomerData and then the validation was successful.
In a related problem, i created a proxy to the webservice and in my test
harness, i picked up an XML file to deserialise and send it . If i put an ns0
prefix for the root element, the deserialisation fails and works only without
the prefix.
Finally if i send data from an orchestration to a remote component and there
is an ns0 in the message (which biztalk normally puts in), then the remote
component is unable to deserialise the message into the corresponding class.
Currently I have used the WSCF tool to generate the web service ASMX file
but the same problems are there without it.
I am totally at a loss to understand why i seem to be the only one with this
problem.
benjy
If you want i can send you a sample of my files.
"Tomas Restrepo (MVP)" wrote:
> Benjamin,
>
> I've never had an issue with this, and the .NET libraries do fully support
> XML namespaces. Mind you, you do not need to get the root element prefixed
> with ns0, all you require is that the element is in the correct namespace
> (the prefix itself is irrelevant and is only used to alias a namespace, and
> it's not necessary if you're using xmlns='' to specify a default namespace).
>
>
> Don't see why you'd need to do this unless you're doing something wrong.
> Usually, the .NET WebService proxy generation tool works just fine and deals
> just fine with namespaces. Perhaps you're defining your webservice in such a
> way that you're generating an incorrect service description?
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>
| |
| Tomas Restrepo \(MVP\) 2006-06-25, 7:23 pm |
| Benjamin,
> Without the ns0 prefix for the root element biztalk throws errors for
> every
> single element in my file. I have to manually prefix with ns0 to get
> through
> the validation. I'll try to explain
>
> A sample of the file i first got from the .NET component was
> <CustomerData xmlns="targetnamespace">
> <fname> </fname>
> <lname> </lname>
> </CustomerData>
>
> This file failed the validation. I then prefixed just the namespace with
> ns0
> and it failed again (Which was to be expected) . So i then manually
> prefixed
> ns0 in front of CustomerData and then the validation was successful.
This means you have an incorrect schema somewhere. What's likely going on is
that somewhere you have your schema configured with
elementFormDefault='qualified' and somewhere else with 'unqualified'.
To be clear:
this:
<CustomerData xmlns="targetnamespace">
<fname> </fname>
<lname> </lname>
</CustomerData>
Is exactly the same as this:
<ns0:CustomerData xmlns:ns0="targetnamespace">
<ns0:fname> </ns0:fname>
<ns0:lname> </ns0:lname>
</ns0:CustomerData>
Both of these work just fine for a schema with
elementFormDefault='qualified', which personally is my preffered way to
define schemas.
However, this is completely different (which is what you're accepting right
now):
<ns0:CustomerData xmlns:ns0="targetnamespace">
<fname> </fname>
<lname> </lname>
</ns0:CustomerData>
This is from a schema with elementFormDefault='unqualified' (which is the
default option, btw), which means that only the root element is qualified
while the inner elements are in the global unnamed namespace ('')
I would guess that the schema you have published as a webservice is from the
first style, while the BizTalk schema itself has the latter.
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| BizTalk Benjamin 2006-06-26, 7:25 am |
| Hi Tomas,
Thanks for the detailed explanation. It Makes a lot of sense. I'll take a
look at the schema design . its probably messed up somewhere in the
elementFormQualified / Unqualified area as you say..
Once again, thank you for your time.
Rgds,
Benjamin
"Tomas Restrepo (MVP)" wrote:
> Benjamin,
>
>
> This means you have an incorrect schema somewhere. What's likely going on is
> that somewhere you have your schema configured with
> elementFormDefault='qualified' and somewhere else with 'unqualified'.
>
> To be clear:
>
> this:
> <CustomerData xmlns="targetnamespace">
> <fname> </fname>
> <lname> </lname>
> </CustomerData>
>
> Is exactly the same as this:
> <ns0:CustomerData xmlns:ns0="targetnamespace">
> <ns0:fname> </ns0:fname>
> <ns0:lname> </ns0:lname>
> </ns0:CustomerData>
>
> Both of these work just fine for a schema with
> elementFormDefault='qualified', which personally is my preffered way to
> define schemas.
>
> However, this is completely different (which is what you're accepting right
> now):
>
> <ns0:CustomerData xmlns:ns0="targetnamespace">
> <fname> </fname>
> <lname> </lname>
> </ns0:CustomerData>
>
> This is from a schema with elementFormDefault='unqualified' (which is the
> default option, btw), which means that only the root element is qualified
> while the inner elements are in the global unnamed namespace ('')
>
> I would guess that the schema you have published as a webservice is from the
> first style, while the BizTalk schema itself has the latter.
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>
| |
| Sultan Abdul Kader [MSFT] 2006-06-26, 7:17 pm |
| Hi Thomas,
Did you get your issue fixed? You should be able to make the Attribute
FormDefault => Unqualified to get it fixed as Thomas says.
Regards,
Sultan
This posting is provided "AS IS" with no warranties, and confers no rights.
Business Process Integration Team
Get Connected!
Meet and interact with key BizTalk Server program managers, developers, and
testers, and let them and other BizTalk Server community team members and
Most Valuable Professionals help you solve your product questions.
Navigate to http://msdn.microsoft.com/subscriptions/support/ in your
webrowser and register as a managed customer to receive MSDN Managed
Newsgroup Support!
MSDN managed newsgroups are available in English to MSDN Universal,
Enterprise, Professional, and Operating Systems subscribers to receive
free, unlimited technical support on select Microsoft technologies as well
as to share ideas with other subscribers.
--------------------[vbcol=seagreen]
<uVsmcb8lGHA.4596@TK2MSFTNGP05.phx.gbl>
<09276ABE-5712-475D-8E11-1A45ED4511D4@microsoft.com>[vbcol=seagreen]
with[vbcol=seagreen]
is[vbcol=seagreen]
right[vbcol=seagreen]
the[vbcol=seagreen]
| |
| BizTalk Benjamin 2006-06-27, 7:20 am |
| Hi Sultan, I am working through and recreating some of the schemas now. As
Tomas said some of them had got messed up when we were setting default
namespaces and target namespaces so we have a situation where some schemas
are correct and work without the ns0 and some dont.
Will post here when i complete the fixes and run tests on them.
Thanks,
Benjy
"Sultan Abdul Kader [MSFT]" wrote:
> Hi Thomas,
> Did you get your issue fixed? You should be able to make the Attribute
> FormDefault => Unqualified to get it fixed as Thomas says.
>
> Regards,
> Sultan
>
>
>
> This posting is provided "AS IS" with no warranties, and confers no rights.
>
> Business Process Integration Team
>
>
> Get Connected!
> Meet and interact with key BizTalk Server program managers, developers, and
> testers, and let them and other BizTalk Server community team members and
> Most Valuable Professionals help you solve your product questions.
>
> Navigate to http://msdn.microsoft.com/subscriptions/support/ in your
> webrowser and register as a managed customer to receive MSDN Managed
> Newsgroup Support!
>
> MSDN managed newsgroups are available in English to MSDN Universal,
> Enterprise, Professional, and Operating Systems subscribers to receive
> free, unlimited technical support on select Microsoft technologies as well
> as to share ideas with other subscribers.
> --------------------
> <uVsmcb8lGHA.4596@TK2MSFTNGP05.phx.gbl>
> <09276ABE-5712-475D-8E11-1A45ED4511D4@microsoft.com>
> with
> is
> right
> the
>
>
|
|
|
|
|