Vincent Scheel - All Comments

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Carsten — Wed, 20 Feb 2013 13:12:29 GMT

Hi Vincent,

Thanks - this helped me.

Just thought i'd mention - I recently had this problem and your solution initialy did not work for me. I got an error with - "There was a failure executing the response(receive) pipeline ... No Disassemble stage components can recognize the data"

As it turned out the problem was that I had two root elements in my schema - and I hadn't specified which one I wanted in "DocumentSpecNames". I had a xxxRequest and xxxResponse element. So I had to add +xxxResponse to get the type name from the Schema name. That may be elementary for others, but it frustrated me for an hour or so...

Regards

Carsten

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Vincent Scheel — Mon, 18 Feb 2013 11:49:46 GMT

Hi Darren,

My apologies for the late reaction. To solve your problem you would use the solution in the blogpost on the OLD receive pipelines. By doing so, the new ports will cast to the new schema's and the old ports will be forced to use the old version.

Good luck!

Kind regards,

Vincent Scheel

IT-grator

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Darren — Fri, 09 Nov 2012 11:44:14 GMT

Hi Vincent i have the following issue and im wondering about the best way to resolve this. Basically i have a biztalk application installed and this application has two receive locations, two receive ports and two send ports.

One set of ports are for live and one set of ports are for pre-production

The problem is they both run off the same underlying schemas and maps.

I have had to update the schemas and maps to add additional elements and my issue is they want to test this in pre-prodcution but obviously if i import the new dll's the live application will also pick these up.

What is the best solution to keep the live application still up and running pointing to the old dll's(schemas and maps) and allow the users to test the new pre-production version on the new version of dll's (maps and schemas).

Thanks

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Vincent Scheel — Fri, 28 Oct 2011 08:38:26 GMT

Dear Siraj,

The situation you suggested was one I had not tested yet. This morning I have tried this in the following way:

Created a project with:

Two schema's in a schema project: input and output - assembly version 1.0.0.0. Both schema's had two child elements: NodeA and NodeB.

One mapping in a map project (version 1.0.0.0): map from schema input to schema output.

I deployed the above artifacts and created a standard File receive to File send test setup, with the map on the ReceivePort.

Then I edited the schema's, adding NodeC and changed the assembly version to 1.0.1.0. I deployed this new schema assembly (note: I did not deploy a new version of the Map project!).

When I removed the map from the receive port and stopped the send port, I could see the message was casted to the new assembly version: 1.0.1.0 by the XmlDisasembler on the ReceivePort.

Then I readded the map to the receive port and tried it again. The outgoing message on the send port was of the OLD assembly version: 1.0.0.0. The map did execute as before.

So it seems that the map does not check the assembly version of an input message (which makes sense, because there is no reference to a assembly version in the entire .btm map file). However, because the assembly of the map references the old version of the schema dll, it does create an output message of the old version.

Hopefully that answered your question! Thank you for visiting my blog!

Regards,

Vincent Scheel

IT-grator

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

ice maker machine — Fri, 28 Oct 2011 01:52:34 GMT

Wow! This blog looks exactly like my old one! It's on a completely different topic but it has pretty much the same page layout and design. Superb choice of colors!

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Siraj — Thu, 27 Oct 2011 18:21:28 GMT

Hi,

Is it possible to use a single biz talk map to handel XML's of different versions?

re: Exposing BizTalk Schemas as a SOAP-RPC/Encoded webservice

air max — Tue, 21 Sep 2010 07:54:18 GMT

I Really enjoyed your blog. I just bookmarked it. I am a regular visitor of your website I will share It with my friends .Thanks.

re: BizTalk BAM event not written from PipelineComponent when port fails

air max — Tue, 21 Sep 2010 07:53:51 GMT

It is my pleasure to read your article, your article is very wonderful. Thank you for sharing!

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Vincent Scheel — Fri, 18 Jun 2010 07:27:26 GMT

Hi Amit,

What you describe is explained by the fact that the receive pipeline automaticly casts the received message to the latest version of the schema. In your case the solution mentioned in my article is not going to work, since you also receive messages of the new type on the same port. Setting the old schema as the DocumentSpecNames property would cause to cast all received messages to the old version (including messages of the new type).

I would suggest creating two sollicit-response ports. One with the DocumentSpecNames property on the receive pipeline set to your old schema version and one with the new version of the schema. You should bind the old version of the orchestration to the send port with the old schema set and the new version of the orchestration to the send port with the new schema set in de receive pipeline.

Hope this helps!

Kind regards,

Vincent Scheel

IT-grator

re: BizTalk: Two versions of a schema side by side and using them in orchestrations

Amit — Wed, 16 Jun 2010 20:36:55 GMT

hi,

i have one application withy version 1, i have modified application and created version 2. both version are calling same web service but different methods in it. i deployed both versions. version 2 is working fine but when version 1 orchestration pick up the message and send to the web service and getting response message it throws error message saying that /* Style Definitions */ table.MsoNormalTable {mso-style-name:"Table Normal"; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-priority:99; mso-style-qformat:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:11.0pt; font-family:"Calibri","sans-serif"; mso-ascii-font-family:Calibri; mso-ascii-theme-font:minor-latin; mso-fareast-font-family:"Times New Roman"; mso-fareast-theme-font:minor-fareast; mso-hansi-font-family:Calibri; mso-hansi-theme-font:minor-latin;} Microsoft.XLANGs.Core.UnexpectedMessageTypeException: Received unexpected message type.

the total error message is

Microsoft.XLANGs.Core.UnexpectedMessageTypeException: Received unexpected message type 'LSC.FundingData.Import.DLF.Orchestrations.SSoADataImportService.Reference+AdultSSoAData, LSC.FundingData.Import.DLF.Orchestrations, Version=2.0.0.0, Culture=neutral, PublicKeyToken=82632b94b069a919' does not match expected type 'LSC.FundingData.Import.DLF.Orchestrations.SSoADataImportService.Reference+AdultSSoAData, LSC.FundingData.Import.DLF.Orchestrations, Version=1.0.1.0, Culture=neutral, PublicKeyToken=82632b94b069a919'.

at Microsoft.XLANGs.Core.XMessage._verifyPublisherSchema() at Microsoft.XLANGs.Core.XMessage.FetchProperties() at Microsoft.BizTalk.XLANGs.BTXEngine.BTXPortBase.ReceiveMessage(Int32 iOperation, Envelope env, XLANGMessage msg, Correlation[] initCorrelations, Context cxt, Segment s) at LSC.FundingData.Import.DLF.Orchestrations.DLFAdultFundingDataImport.segment6(StopConditions stopOn)

at Microsoft.XLANGs.Core.SegmentScheduler.RunASegment(Segment s, StopConditions stopCond, Exception& exp)

Microsoft.XLANGs.Core.UnexpectedMessageTypeExceptionScoped@

DLFAdultFundingDataImport.??__scope34

DLFAdultFundingDataImport.??__scope33

DLFAdultFundingDataImport.DLFAdultFundingDataImport

20d2d333-4794-4976-a37d-21544dfe0587

as per my understanding when orchestration sends message to webservice and getting reply back from web service there are two subscriber for response one is version 1 orch adn second is version 2 orch and by default it is picking up by the second version orch.

if that is right can you help me to solve this?

re: BizTalk BAM event not written from PipelineComponent when port fails

Patrick Wellink — Thu, 08 Apr 2010 08:25:41 GMT

Hee Vince,

Nice to see you figured it out by yourself. (could have given me a call though...)

The same behaviour you get with inspecting the message. Say you have three pipecomponents and each alters the message. You would expect that if the pipeline fails on pipecomp 3 you would get a message altered by pipecomp 1 and 2. However the original incoming message (so before it enters the pipeline) is stored. Funny enough though... Any context props that you modify and add are stored. So context is not rolled back ( I use exactly this functionalitu in BBP for resubmits on failed messages).

Anyway back to your issue :

I believe that that last issue ( write to bam if send failes is solved with SP1)

see : 942024 (support.microsoft.com/.../942024 ) FIX: A Business Activity Monitoring (BAM) activity is not rolled back when the send port fails in delivering the output message in BizTalk Server 2006

However DO NOT INSTALL SP1 !!!!!!!!

it's utter crap..... As far as my experience goes it breaks the following :

1. Disassembly in receive pipelines

2. The complete WCF database stuff....

3. And there is more

Nice to know you'r still BizTalking........ !!!!!!!!!!!1

re: BizTalk BAM event not written from PipelineComponent when port fails

Vincent Scheel — Thu, 08 Apr 2010 06:52:20 GMT

Thanks for your comment Thiago. I just tried and I do not get the same behaviour with a send port. The send port writes to BAM even if the port fails.

So I have the same finding as you!

Regards,

Vincent Scheel

re: BizTalk BAM event not written from PipelineComponent when port fails

Thiago Almeida — Wed, 07 Apr 2010 21:20:39 GMT

Nice to know Vincent, and it makes sense. It uses the same transaction as the endpoint manager does to write the message to the message box, and if it fails it gets rolled back.

I wrote a post talking about using the underlying connection on a receive port:

connectedthoughts.wordpress.com/.../hooking-into-biztalks-underlying-transaction-in-your-custom-receive-pipeline-component

Have you tried this on a send port as well to see if it also rolls back? From my experience while writing that blog post I was only able to hook into the transaction on the receive pipeline.

Regards,

Thiago Almeida

re: Exposing BizTalk Schemas as a SOAP-RPC/Encoded webservice

Rob van Duijn — Mon, 18 Jan 2010 20:20:40 GMT

Nice post!

re: Exposing BizTalk Schemas as a SOAP-RPC/Encoded webservice

Patrick Wellink — Wed, 13 Jan 2010 07:01:02 GMT

Hee, welcome to bloglines.

Nice article, hope i will need this in the future.