Home Page › Forums › BizTalk 2004 – BizTalk 2010 › unable to change orchestration subscriptions
- This topic has 6 replies, 1 voice, and was last updated 8 years, 4 months ago by
community-content.
-
AuthorPosts
-
-
August 11, 2010 at 7:56 AM #25598
Hi the Gurus,
I came across a very weird behavior while deploying a project in BTS 2006 R2 SP1 (+ cumulative pack 1 and 2).
I wanted to see how to do sequential covoys with a simple test orchestration.
First I built and deployed the orchestration, without correlation, using logical ports (define later, one-way). I then bound the orchestration to the host and physical ports, and that was it, it ran exactly as expected.
Then I add the correlation. Deployment was OK, but in the Admin Console everything went wrong, I was able to update orchestration bindings but not to enlist it, the console fired following exception :
Event Type: Error
Event Source: XLANG/s
Event Category: None
Event ID: 0
Date: 11.08.2010
Time: 13:06:33
User: N/A
Computer: VMBTSDEV01
Description:
NullReferenceException exception occurred while the XLANG/s runtime enlisted a service.
Error message:Object reference not set to an instance of an object.
Call stack: at Microsoft.BizTalk.XLANGs.BTXEngine.BTXServiceStaticState.CreatePortInfoTable(OrchestrationMetadata orchMetadata, Hashtable portToLrp)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXServiceStaticState.PersistState(String mgmtDBServer, String mgmtDBName, String MsgBoxGroupName, String ApplicationName, String serviceAssembly, String serviceTypeName, Guid[] PortIDs, Guid[] LrpIDs, Delegate satAssemblyCacheCallback, ITransaction transaction)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXService.GoLive(String configDBServer, String configDBName, String msgBoxGroupName, String applicationName, String servicePath, String serviceTypeName, Guid[] portIDs, Guid[] lrpIDs, Delegate satAssemblyCacheCallback, ITransaction transaction)
Exception type: BTXEnlistmentException
Additional error information:Object reference not set to an instance of an object.
Exception type: NullReferenceException
Source: Microsoft.XLANGs.BizTalk.Engine
Target Site: System.Collections.Generic.Dictionary`2[System.String,Microsoft.BizTalk.XLANGs.BTXEngine.BiztalkPort] CreatePortInfoTable(Microsoft.BizTalk.XLANGs.BTXEngine.OrchestrationMetadata, System.Collections.Hashtable)
The following is a stack trace that identifies the location where the exception occuredat Microsoft.BizTalk.XLANGs.BTXEngine.BTXServiceStaticState.CreatePortInfoTable(OrchestrationMetadata orchMetadata, Hashtable portToLrp)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXServiceStaticState.PersistState(String mgmtDBServer, String mgmtDBName, String MsgBoxGroupName, String ApplicationName, String serviceAssembly, String serviceTypeName, Guid[] PortIDs, Guid[] LrpIDs, Delegate satAssemblyCacheCallback, ITransaction transaction)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXService.GoLive(String configDBServer, String configDBName, String msgBoxGroupName, String applicationName, String servicePath, String serviceTypeName, Guid[] portIDs, Guid[] lrpIDs, Delegate satAssemblyCacheCallback, ITransaction transaction)After 1 day of testing, searching, checking, trying, crying (ok, not really…), and although Mr Google and Mr Bing helped me quite a lot, I couldn’t find any better solution than systematically stop and restart the admin console when deploying Orchestration with subscription changes.
It seems that all cached data doesn’t get refreshed after deployment. I could point this because after the addition of a Filter Expression on the receive shape, the subscription showed in the console (query “Search for” ==> subscriptions, “Service Name” ==> my orchestration) didn’t get updated ; after the console was restarted, and the orchestration redeployed and reenlisted, the subscriptions where refreshed.
I could’nt find a post in any forum/blog that would be similar to this problem. Do you have an idea where it could come from? Any suggestion to correct this and avoid loosing time in reopen the admin console ?
Thanks for your advices!
best regards
Thomas -
August 11, 2010 at 8:07 AM #25599
Oups, wasn’t logged in…
-
August 11, 2010 at 10:46 AM #25603
Hi Thomas,
Did you make sure to restart the host instance and check that the orchestration DLL is installed in the GAC (with the correct version)?
Daniel.
-
August 11, 2010 at 11:41 AM #25605
Hi Daniel,
Thanks for replying.
Host instance was restarted during the deployment process by VS. The dll was in the GAC and in some cases I tried to unregister it manually before deployment, VS put it back.
Thomas
-
August 11, 2010 at 12:32 PM #25606
Hi Thomas,
Did you also verify that your orchestration’s logical ports were properly configured?
-
August 11, 2010 at 11:08 PM #25609
I did many variations with ports. In VS I recreate the locigal ports, changing them from “define later” to “define now” and to “Direct Binding”, I also tried to drop and recreate the porttypes only, but nothing helped. And in the console I verified that the bindings were corrects and I changed them some times.
-
August 12, 2010 at 2:17 AM #25612
OK, I made some more tests and here is a small update.
The exception I mentioned earlier occurs when I change the port binding
in VS, e.g. from “Specify Later” to “Direct Binding”. It won’t be fired
when I only change the Filter Expression.In the latter case, I can enlist the orchestration but its subscriptions
won’t be updated, that means the orchestration will continue to
subscribe to messages that comply to the preceding filter ; as mentioned
I am 100% sure that the host instance and the GAC are up to date, and
there is no suspended message.I mentioned that I looked to the subscriptions with a specific query, I
found out that when unenlisting the orchestration, subscriptions stay to
“stopped”, it won’t be “disabled” nor be deleted. These subscriptions
problems come up only with orchestrations, the same tests on send ports
are sucessfull.I also tried to deploy my orchestration from dev environment and then
manage artefacts from staging (distant). Un- and enlisting still didn’t
update orchestration subscriptions at all.Latest thing I tryed was to rename the orchestration (e.g. from “test”
to “newTest”) ; in that case, subscriptions were updated as expected,
but only at 1st deployment ; if I change them a second time, the problem
comes back. And to this : if I re-change it from “newTest” to “test”,
the “old” orchestration comes back with its old subscription conditions !All these tests were made with Admin Console opened and simply refreshed
(F5) ; when I close and reopen it, everything works all right, except
that orchestration subsciptions keep their “stopped” state despite
unenlisting them. This is also true when I manage the artefacts from a
distant console.I have to make clear that I installed the SP1 and the cumulative
correction packs 1 and 2 in the last weeks, and that is the first time
that I am “playing” with orchestrations and subscriptions. I didn’t see
anywhere that VS or the admin console needed to be updated separately,
maybe I’m missing a fix or another KB article ?Next steps will be :
– reinstall admin console
– reinstall VS Biztalk add-ins
– try to deploy my orchestration on my staging environment.Any suggestion will be fully appreciated, thanks a lot!
Thomas
-
-
-
-
-
-
AuthorPosts
- The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.