Hi

In my RSS aggregator I have the sourceforge file releases for dasBlog as a feed.

So the other day I read that a new version of dasBlog had been released.

Well, today I have finally had the opportunity to upgrade to the new version.

Should you notice anything weird, please let me know.

--
eliasen

Hi

I received the diploma for passing the 74-135 exam in BizTalk server 2004 the other day.

And... well... see if you can spot the error:

I have phoned support. They will correct it and send me another diploma. Until then, I am very proud to be the only person in the world (unless anyone else has gotten the same diploma?) that is certified in BizTalk Server 2003 :D

--

eliasen

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