Hi

A colleague of mine, Morten la Cour Thomsen, who is "MCTS: BizTalk Server 2004" AND "MCTS: BizTalk Server 2006" discovered something strange the other day. In fact, it is so strange, that I thought I'd share it here on my blog.

Morten was on a project, where he had taken over another persons BizTalk solution. Unfortunately for Morten, the other guy had decided to put all artefacts into one single assembly. That's right - all schemas, all maps, pipelines, orchestrations.. the works! Just one big assembly.

This turned out to be quite a problem for the company that had this solution, since versioning any single artefact meant versioning the whole thing. That is also why they until now didn't version anything. Should something need to be changed in the big assembly, four steps were performed:

1. Stop all receive locations
2. Make the change in the artefact that needed changing
3. Wait until all long running transactions have stopped
4. Deploy the new assembly on top of the old one, leaving all versionnumbers the same

Mortens job was to create a better architecture, since it really wasn't ok with the customer to have to stop receiving new messages until all orchestrations had stopped.

One of the steps Morten came across was that he actually at some point needed to call an orchestration that was inside this big assembly. The orchestration that Morten needed to call was being called from other orchestrations inside the assembly, so it was ready to be called (no activate receive shape, etc.). The only problem for Morten was, that the orchestration, off course, was internal to the assembly. Morten could reference the assembly, but he couldn't call the orchestration from within an "Call Orchestration"-shape.

But that's when Morten tried something that I would never have thought of trying: He had the source code for the big assembly. And he had the keyfile that had been used to sign it. So he changed the orchestration to be public, recompiled the big assembly, referenced the newly compiled assembly, added the former internal orchestration to his "Call Orchestration"-shape and compiled his own assembly.

He now deployed his own assembly, but left the old big assembly in place.

Now he had the old big assembly, which still had the internal orchestration inside it. And he had another deployed assembly, which was compiled against the source code with a public orchestration. The big assembly was never redeployed!

But it worked! Mortens orchestration is now calling the internal orchestration of the other assembly, simply because it was compiled against a public orchestration and the signature of the deployed big assembly matches the signature of his newly compiled big assembly.

Very weird, indeed. And it probably isn't meant to do that...

I have a sample solution for BizTalk 2004 you can look at right here: InternalOrchestration.zip (132 KB)

And two sample projects for BizTalk 2006 right here: Calling Internal Orchestration.zip (146,46 KB)

In both cases, the code reflects the internal orchestration AFTER it has been set to public. What you want to do is to

1. Set the type to "internal" on the called internal orchestration.
2. Build and deploy the assembly with the internal orchestration.
3. Test it to see that it works.
4. Try to build the other assembly. It will fail because of the internal orchestration.
5. Set the type to "public" on the called orchestration.
6. Build and deploy the second assembly WITHOUT redeploying the first assembly.
7. Test it to make sure it works.

So, basically, now you have a way of calling an internal orchestration, as long as you have the source code for it and the key to sign it.

Hope this is useful for someone.

--

eliasen

Hi

A guy (I think it is a guy, anyways ) on the microsoft.public.biztalk.orchestration newsgroup has a problem with this issue. And since I had the issue myself a long time ago, and always wanted to write a quick blog entry about it, this seemed like a perfect time for it

A quick note: This issue appears on both BizTalk 2004 and BizTalk 2006.

So basically, the problem is: When compiling a BizTalk project, you get the "'projectname.orchestrationname': cannot resolve imported 'service'" error. This occurs when you are compiling a project that has an orchestration inside it, that calls another orchestration in another project that again calls an orchestration in a third project. Confused? I bet! I will give you details, screenshots and explanations in just a few lines.

The quick answer is: The project you are trying to compile must reference the third project.

BUT, to the long answer:

I have created a solution with three projects:

• ProjectA with ABCSchema.xsd and OrchestrationA.odx
  • Orchestration A does this
    • Receive a message of type ABCSchema.xsd
    • Initialize a string variable to receive the value from a distinguished field in ABCSchema
    • Write the value to the eventlog
    • Call OrchestrationB
• ProjectB with OrchestrationB.odx
  • Orchestration B does this:
    • Receive the string parameter from OrchestrationA
    • Write the value to the eventlog
    • Call OrchestrationC
• ProjectC with OrchestrationC.odx
  • Orchestration C does this:
    • Receive the string parameter from OrchestrationB
    • Write the value to the eventlog

Screenshots:

The (very small) schema:

OrchestrationA:

OrchestrationB:

OrchestrationC:

No hokus pokus at all!

In order to call OrchestrationC from OrchestrationB, I added a reference to ProjectC from ProjectB. Both ProjectB and ProjectC compile just fine.

In order to call OrchestrationB from OrchestrationA, I add a reference to ProjectB from ProjectA, but ProjectA wont compile. I get this error:

The famous "cannot resolve imported 'service'" error.

BUT, referencing ProjectC from ProjectA solves this issue, and I can compile just fine.

Actually, the error description indicates it. When compiling ProjectA, it can't import the "ProjectC.OrchestrationC" service. But often, you are maybe compiling the entire solution, and you just see that the file in quesion is projectb.dll. But the error just states that ProjectA cannot import ProjectC.OrchestrationC, which it needs to according to projectb.dll.

Should anyone think that it is really silly that ProjectA needs to reference a dll that another dll references and that this breaks all nice architectures, I would agree. If someone gives me a set of 20 dll's that make up a nice solution he/she has made, and I need to call an orchestration in one of them, then I also need to reference all the dll's that this one dll references, assuming there are internal "Call Orchestration"s between these dll's. I will need to know how these dll's reference eachother in order to reference one of them. Really silly, indeed.

I don't know why they have made it like this, but they have.

I hope this post helps others.

Should you have comments, please don't hesitate... My three projects can be found here: A_calls_B_calls_C.zip (137,08 KB)

--

eliasen

Hi

Today, I had the pleasure of helping a fellow BizTalk guy on the microsoft.public.biztalk.general newsgroup. He has a schema which showed up with lots of root elements in the schema editor. He wanted to fix that, but how?

The "problem" is well known if you for instance use schemas created by InfoPath 2003. They will look something like this:

There are lots of elements that appear to be the root node. Now, I know that "myFields" is the actual root node that I want to use, but it sure isn't easy to see. What I want shown is this:

And if I create an instance of this schema, I will get this:

<ns0:CustomerName xmlns:ns0="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45">CustomerName_0</ns0:CustomerName>

But that isn't what I wanted. I wanted this:

<ns0:myFields ns1:anyAttr="anyAttrContents" xmlns:ns1="http://www.w3.org/XML/1998/namespace" xmlns:ns0="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45">
  <ns0:CustomerName>CustomerName_0</ns0:CustomerName>
  <ns0:OrderLines>
    <ns0:OrderLine ns0:ID="ID">
      <ns0:Description>Description_0</ns0:Description>
      <ns0:Quantity>100</ns0:Quantity>
      <ns0:ItemID>100</ns0:ItemID>
    </ns0:OrderLine>
    <ns0:OrderLine ns0:ID="ID">
      <ns0:Description>Description_0</ns0:Description>
      <ns0:Quantity>100</ns0:Quantity>
      <ns0:ItemID>100</ns0:ItemID>
    </ns0:OrderLine>
    <ns0:OrderLine ns0:ID="ID">
      <ns0:Description>Description_0</ns0:Description>
      <ns0:Quantity>100</ns0:Quantity>
      <ns0:ItemID>100</ns0:ItemID>
    </ns0:OrderLine>
  </ns0:OrderLines>
</ns0:myFields>

So, how do I achive this?

Well, the answer is quite simple, really... although it does involve manually editing the schema file (the .xsd file).

What you want to do is add a BizTalk specific annotation to the schema to let BizTalk Schema Editor know which node is to be treated as the root node.

So my schema looked like this:

<xsd:schema xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:attribute name="ID" type="my:requiredString" />
  <xsd:element name="myFields">
... and a whole bunch more

and I edited it and now it looks like this:

<xsd:schema xmlns:my="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45" xmlns:b="http://schemas.microsoft.com/BizTalk/2003" targetNamespace="http://schemas.microsoft.com/office/infopath/2003/myXSD/2006-09-07T18:24:45" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
  <xsd:annotation>
    <xsd:appinfo>
      <b:schemaInfo is_envelope="no" version="1.0" root_reference="myFields" displayroot_reference="myFields" xmlns:b="http://schemas.microsoft.com/BizTalk/2003">
      </b:schemaInfo>
    </xsd:appinfo>
  </xsd:annotation>
  <xsd:attribute name="ID" type="my:requiredString" />
  <xsd:element name="myFields">

So under annotations under appinfo, I added a BizTalk specific schemaInfo element, which describes which node to treat as the root node.

Clever and simple. But remember that you need to do this editing every time a new version of the schema needs to be used.

You can find my schemas here:

myschema.zip (,78 KB)

and here:

correctedmyschema.zip (,88 KB)

 

I hope this helps someone.

--

eliasen

Hi

Well, today was the day where I passed the 70-235 exam in BizTalk Server 2006.

So now I have passed all three BizTalk exams - BizTalk 2000, BizTalk 2004, and BizTalk 2006. Anyone else who has done that?

I wonder how soon I can order my welcome kit at microsoft.com/learning

--

eliasen

Hi

Today I ran into a problem configuring the WSS Adapter for BizTalk 2006. In the configuration wizard I just couldn't choose a web site for the adapter that would satisfy the configuration wizard. I got this error:

And I was pretty tired of it Especially because I was sure WSS was installed on this web site, the web site was extended with WSS and everything should have been ok.

Anyway, some searching on the net gave me a hint as to what was going on. I found an article on topxml.com that helped me. In short, I had installed Windows Sharepoint Services on a web site I had created for this purpose, but I had forgotten to make sure the web site was running ASP.NET 2.0 before installing WSS. This made WSS run on .NET 1.1 and BizTalk 2006 has a requirement that it must run under .NET 2.0.

So in order to register ASP.NET 2.0 with IIS and upgrade my WSS installation to use .NET 2.0, I ran the following two commands:

"c:\windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis.exe" -i

"c:\program files\common files\Microsoft Shared\web server extensions\60\BIN\STSADM.exe" -o upgrade -url http://localhost:4242 -forceupgrade

The :4242 is because my WSS web site is configured to run on this port.

After this, there were no problems, and I could then configure the WSS adapter. I didn't need to restart the configuration wizard - I just had to select the default web site and then select my WSS Site again.

Hope this helpes someone. Should you have comments, please go ahead.

--

eliasen

Hi

I ran into this one a while ago. I couldn't find any information about the error on the internet, so I tried the microsoft public newsgroups. Again, no help (although those newsgroups are a GREAT place for getting help...). Anyway, I found out, what the error was, and it can probably be found in google groups by now, but I thought I'd just share it here as well.

Basically, the problem was that BizTalk 2004 SP1 apparently has a bug. If you have a "Call Orchestration"-shape (or a "Start Orchestration"-shape) in your orchestration, and this shape is placed in some particular unreachable code, you get this error.

I had a decision shape in my orchestration, but I hadn't gotten around to deciding what the rule in the decision shape was going to be. So I entered "1 == 1" in order for the assembly to compile and then I could deploy it and test it for that branch of my decision shape. Then, I wanted to test the other branch, still not knowing what the final rule would be. So I modified the orchestration to have the rule to be "1 != 1" - but then I couldn't compile - weird, eh?

Below is my orchestration.




So, as you can see - no funny stuff. Another weird thing is, that I can compile just fine with my "Call Orchestration"-shape after a Terminate-shape. But that is unreachable code as well.

I don't know what is happening, but it sure is weird.

I hope this posting has helped some of you.

You can find a copy of my project here: CompileErrorWhenDecisionShapeRuleIsFalse.zip (59.09 KB)

Let me know if you have any comments.

--
eliasen

Hi everyone!

Three weeks ago, my second son was born. So now I am the proud father of two sons.

They have a homepage, my sons... it can be found at http://andreas-og-emil.eliasen.dk

It is only in Danish, I'm afraid.

Oh yeah, and it is my first attempt at making anything in ASP.NET 2.0 - and I've even used the Masterpage functionality

--
eliasen

Hi, and welcome to my very first blog entry here at http://blog.eliasen.dk - I hope to be able to blog about some issues I run into using BizTalk and other server products from time to time.

Let me know if you have any questions and/or comments for me.

--

Eliasen Jr.