- This topic has 8 replies, 1 voice, and was last updated 7 years, 3 months ago by
.
-
Posts
-
-
When you check it on Windows 2003 – does that have SP1 for Biztalk installed? I think SP1 changed some namespace requirements that might affect this.
As far as a workaround, I think it is important to have a namespace on each of the messages you are using as input and output of the transformation. Do they already have namespaces?
-
Did any of the namespace change since you created the map?
About the only other thing I can think of is to re-import you source schema and more or less redo the map. Make sure you redo the transform shape as well. I have seen that work in the past.
If you get it to work, please let me know.
-
If you wanted to zip up the project, I would be happy to take a look at it.
You can find my email on the contact page or in my profile.
-
You might also want to try putting them all in different assemblies – or at least not putting the map with the orchestration. You should be ok putting schemas and maps together.
Just something else to try.
-
We have two incoming messages to an Orchestration. Data from both of these messages are to be used to construct another message which will be sent to an external system.
Of the two incoming messages, one is fairly simple with a mix of records and elements, the other is complex, built up of a number of extended types from schema dictionaries.
Using Windows XP SP2 workstations with .Net 2003, BizTalk developer tools etc installed (all have .Net 1.1 SP 1, BizTalk 2004 SP1 and one has the BizTalk rollup), the complex schema does not display properly in the source pane of the mapping tool when this is part of a two-message input via the Transform shape.
What seems to be happening is that any element declared on the base data type in the schema is missing, while properties on the extended type are OK. If the map is changed to only input the one, complex schema, everything displays correctly.
Also, a colleague running Windows 2003 Server with Visual Studio and BizTalk has tried this, and on that environment, the complex schema displays correctly when part of a two message mapping source.
It would appear as if the Server 2003 environment has a BizTalk, Studio or .Net Framework patch that we do not have on the XP environments, however all that we have examined suggests that we do in fact have all the same service pack, framework patch levels etc.
The following screen captures illustrate what we are seeing when we have the two message input on XP:
[img:158574d987]http://www.eveleigh.f9.co.uk/images2/fig1.jpg[/img:158574d987]
The \”FMAApplication\” record shows a single sequence containing four records, the first of which contains two fields. What it should look like (if the map is changed to have just the complex schema in place) is as follows:
[img:158574d987]http://www.eveleigh.f9.co.uk/images2/fig2.jpg[/img:158574d987]
As you can see, there are far more sequence groups, records and fields in the full Schema!
For info, the transformation shape in the Orchestration is being configured as follows:
Source transform:
[img:158574d987]http://www.eveleigh.f9.co.uk/images2/fig3.jpg[/img:158574d987]Destination transform:
[img:158574d987]http://www.eveleigh.f9.co.uk/images2/fig4.jpg[/img:158574d987]Any thoughts or suggestions as to what fixes/patches we may be missing, or configuration we may have missed to resolve this would be really appreciated.
-
Steve
Yes the 2003 machine has BizTalk SP1 (as well as 2003 SP1) – the XP machines have BizTalk SP1 as well.
All 3 messages have namespaces declared
Regards
-
Stephen
Thanks for taking the time to look at this and reply.
We have started with new projects in case anything was corrupted, but the same problems apply. The namespaces have not changed, and as yet we have not really started the mapping process – I wish we could get that far – most of the fields we are after are those not visible in the complex schema.
I will try to reproduce this in a simple contained project and post back the results of this.
Regards
Mark-
Stephen
We have made some progress with this. A colleague has found that by including an xsd in the overall solution more than once, we have the problem, i.e. we effectively have xsd files with the same target namespace. Changing the namespace in copies of the file resolves the problem.
We did this deliberately to minimise the impact of change (or at least give us some flexibility of when things get released).
Specifically, we have a BaseDictionary.xsd that defines a number of common types. These are primarily simple types with restrictions, such as enumerations or regex validation. We shared (using sourcesafe) this dictionary into each schema project that we needed to use the base types, instead of referencing a base project, on the basis we could choose when to update the specific schema project if the base dictionary changes.
The schema projects used in the solution for this thread all use the base dictionary, so each of them have, effectively, their own copy of the basedictionary schema that has the same namespace. If the namespace is changed to be unique, the problem goes away.
So, we now know how to get the map to work, but we need to rethink our approach to the deployment side should things change.
Thanks for your help & suggestions.
Regards
Mark
-
-
-
-
-
-
-
-
Hi,
I don’t know where eveleighm left this issue with you (as I haven’t spoken to him since friday), but we have been tinkering with the project to see what we can find out in his absence.
Initially we were looking at a number of different assemblies within the solution. One with the Biztalk Orchestration and Map, and a number of others defining the XML Schemas (typically with a schema \”dictionary\” and then a number of schemas).
This gave us the problem as outlined in the original post.
Another collegue has since tried placing these schemas (and the associated schema dictionaries) in the same assembly alongside the Orchestration and Map. The complex schema is then correctly shown in the Map.
Whether this helps with figuring out what the initial problem is (or why our other absent collegue doesn’t seem to have this problem) is another matter!
Cheers
Stu.
-
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.