IvanJo's thoughts

Problem: Enterprise Single Sign-On (ENTSSO) doesn't start automatically upon system restart

2007-07-20T15:11:00.000+01:00

I've experienced strange case these days. We have three BizTalk 2006 servers and SSO service clustered on active-active database cluster. Everything works fine, but when we restart any of biztalk servers, EntSSO does not start automatically on those.
The strange thing is that logging in thru RDP and starting the service manually (net start or from Services panel) it starts without any problem.
When starting automatically, it shuts down with error: Access is denied.

The problem has been solved by adding a registry key pointing to the IP of a clustered SSO service name. Follows .reg file:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSSQLServer\Client\ConnectTo]
"ForSSO"="DBMSSOCN,127.0.0.1"

Remember to change 127.0.0.1 for your valid SSO service name IP

Cheers,
Ivan

Freeware SOAP Testing

2007-03-27T10:56:00.000+01:00

I've been searching for valid freeware SOAP testing tool for a time.

I've tried SOAPSonar but it was not able to set request timeout (at least in the version that I've tried out).

I find SOAP UI very useful. It has some interesting features like:

Inspect and Invoke

Implement and Validate

Functional Test

Load and Stress Test

Here's application screenshoot:

BizTalk 2004/2006 versioning

2007-03-21T14:10:00.000+01:00

The original request of a client was: "We want our partners connecting in staging and production environment but on the same BizTalk servers"

I've started searching about this matter, but nothing found to help, so I've started thinking. Finally a solution to the problem was found.

Scripts were developped for automatic versioning, build and deployment in test, preproduction and production environment.

What do you need to successfully version a set of schemas, pipelines, pipeline components, orchestrations etc. :

Schema versioning:

XML namespace must be in some way "dynamic" (eg. http://mynamespace.com/__ASSEMBLYVERSION__/messageA)
If you use "Quick promotion" that you should also version namespace of PropertySchema.xsd schema
Namespace of schema (when you click on a .xsd file) should be of form: org.MyOrg.__ASSEMBLYVERSION__.schemas and you preserve Type of schema
AssemblyVersion should be set to the progressive version being built (it's located in .btproj file)

Orchestration versioning:

After schemas are prepared you can use them in orchestrations. These do not need any particular modification
AssemblyVersion should be set to the progressive version being built (it's located in .btproj file)

Custom pipeline versioning:

DefaultNamespace should be as: org.MyOrg.__ASSEMBLYVERSION__.pipelines (it's located in .btproj file)
AssemblyName should be as: org.MyOrg.__ASSEMBLYVERSION__.pipelines - this will help when you GAC assemblies later in the deployment phase (it's located in .btproj file)
Assembly version should ramain set to 1.0.0.0 (it's located in .btproj file)

Custom pipeline components:

If you need to perform any action on XML document load from stream you should remember that XML namespace used is dynamic..

In general all DLL's should have the same assembly version (the progressive one), but DLL's having custom pipelines should have version set to 1.0.0.0 and in the assembly name have this version incorporated.

Another important thing is that when you do a replace of __ASSEMBLYVERSION__ macro in pre-build stage you should keep it in form of _1_3_15_1000_ so it is accepted as a part of .NET namespace, XML namespace and file name...

Hope that someone will find this blog usefull ...
Just to mention that this system is live for more than 2 years in production environment of important client.

Ivan Jocic