I created two schema that are identical except for one thing.
One of them has an extra element after the max-occurs=unbounded.
First schema – DemoRequest1.xsd
Second schema – DemoRequest2.xsd
I then created two identical orchestrations, except one receives DemoRequest1 and one receives DemoRequest2 (they both return the same message in the response).
Then both orchestraiton were published as WCF services.
We can see the differences in two ways:
1) By using the WCFClientTest.exe utility (found here:
C:Program FilesMicrosoft Visual Studio 9.0Common7IDE)
2) By creating a C# program, and adding a service reference to the published orchestration (WCF web service)
WCFTestClient shows the following:
The results are perhaps more clear in C#:
static void Main(string args)
svcref1.Demo1Request req1 = new WCFOddityConsumeConsoleApp.svcref1.Demo1Request();
svcref1.Demo2Request req2 = new WCFOddityConsumeConsoleApp.svcref1.Demo2Request();
req1.DemoRequest1.MyString = "abc"; //Note the element ?MyGroup? does not even appear here!
req1.DemoRequest1.MyDecimal = 123;
req2.DemoRequest2.MyGroup.MyString = "abc";
req2.DemoRequest2.MyGroup.MyDecimal = 123;
req2.DemoRequest2.AfterMyGroup = "test";
You can see how in one case, the “MyGroup” element has totally disappeared, and the subscript is now on it’s parent element!
So the moral of the story is, we sometimes add a “DummyElement” after the maxOccurs=unbounded group/record – so the world seem more normal.
1) This one comes with Visual Studio:
C:Program FilesMicrosoft Visual Studio 9.0Common7IDEWCFTestClient.exe
a) Just add your the URL to your service
b) double clik on the method you want to call
c) fill in the values
d) click invoke
It shows the response formatted, and there is an XML tab to show you the full XML.
2) CodePlex has several:
3) http://www.soapui.org/ – Free and paid version – I think you have to register to get the free version.
If you want to do Load Testing – http://wcfloadtest.codeplex.com/
BizTalk itself can be installed and configured in about an hour if everything goes well.
If you are starting from scatch however, you should probably allow at least one full work day. By this, I mean you build a Virtual PC or a new machine and install all the prerequisites.
Here is a list of things I installed on a new Virtual PC, in preparation for creating a new WCF/BizTalk course:
Windows 2003 – about 1.5 hours
Windows 2003 SP2 – about an hour
SQL 2005 – about an hour
SQL 2005 SP3 – about an hour
Visual Studio 2005 – about an hour
Visual Studio 2005 SP1 – about an hour
Visual Studio 2008 – about an hour
Visual Studio 2008 SP1 – about 1.5 hours
Create userids and groups before BizTalk Install – about 10 minutes
BizTalk 2006 R2 – about an hour
It all adds up fast. All the above take about 10 hours, but you can be doing other things while all the installs are running.
I did the above on a 500 GB USB drive, so it might actually run faster on a real machine, local disk, non-virtual.
I did not include SharePoint or MOSS on the above install. The time above also excludes the time to install Office (Excel and Infopath – needed for BAM and Trading Partner Management).
ESB vs Biztalk Debate Gets Heated in Barcelona – While giving a presentation at the Enterprise Architect Summit in Barcelona, on It turned into a pretty heated debate over core architectural fundamentals, which we hammered out in front of an audience of about 75 unsuspecting conference-goers….
Set @Jobname = N’ESB_LaSalle-Loan-Removal-Monthly’
SELECT @Jobid = job_id FROM msdb.dbo.sysjobs WHERE (name = @Jobname)
select ‘job1’, @jobid, @jobname
IF (@jobId IS NOT NULL)
exec sp_delete_job @job_name=@Jobname;
“Cannot add, update, or delete a job (or its steps or schedules) that originated from an MSX server.” +”originating_server_id”
I got this error when doing the following. I did right-click ‘Create Job as” then “Create to” a new query window. I was scripting 3 SQL agent jobs, then tried to combine them into one script.
I was trying to build my script without any “GO” commands, so I could have some variables at the top used throughout as parameters.
It was critical to reset these variables before each call to sp_add_job:
SET @ReturnCode = null
SET @jobID = null
The other “hits” I found when googling were totally off target of my solution above. I’m using SQL 2005, which seems to have an “originating_server_id” instead of an “originating_server” in the sysjobs table.