This project is read-only.

BRE.EXT Invocation Exception - solved

Mar 3, 2010 at 3:26 PM
Edited Mar 3, 2010 at 8:05 PM

Hi

I've installed the extensions on a development box with VS2008, Win2008 Std SP2 32-bit (locale sv-se) with BTS2009 and ESB Toolkit 2.0, but bumps into a invocation exception when I'm trying to use the BRE.EXT resolver (see logged event below) Can't figure out whats going wrong... esb.config looks ok with BRE.EXT registred and showing up in ItineraryDSL etc. Standard BRI resolver is working fine.

My simple test scenario: A file receive location with Itinerary select (BRE.EXT) using the default ItinerarySelectReceivePassthrough pipeline. Exception is thrown by the ItinerarySelector in the pipeline when using BRE.EXT Same exception is thrown if I try to test the resolver from Itinerary designer.

Itinerary Selector configuration:

  • IgnoreErrorKey=False
  • ItineraryFactKey=Resolver.Itinerary
  • ResolverConnectionString=BRE.EXT:\\policy=ResolveItinerary;useMsg=true;version=;recognizeMessageFormat=true;useMsgCtxt=true;msgCtxtValues=;
  • ValidateItinerary=False

Any suggestions on what to do?

Cheers

/Henrik

=== Event log exception ===

Event Type: Error
Event Source: BizTalk ESB Toolkit 2.0
Event Category: None
Event ID: 5050
Date:  2010-03-03
Time:  16:01:13
Description: Exception has been thrown by the target of an invocation.

Source: Microsoft.Practices.ESB.Itinerary.PipelineComponents.ItinerarySelector

Method: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute(Microsoft.BizTalk.Component.Interop.IPipelineContext, Microsoft.BizTalk.Message.Interop.IBaseMessage)

Error Source: mscorlib

Error TargetSite: System.Object _InvokeConstructor(System.Object[], System.SignatureStruct ByRef, IntPtr) 

Error StackTrace:    at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)
   at System.RuntimeMethodHandle.InvokeConstructor(Object[] args, SignatureStruct signature, RuntimeTypeHandle declaringType)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Practices.ESB.Resolver.ResolverFactory.Create(String key)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.GetResolver(ResolverInfo info)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(ResolverInfo info, IBaseMessage message, IPipelineContext pipelineContext)
   at Microsoft.Practices.ESB.Itinerary.PipelineComponents.ItinerarySelector.Execute(IPipelineContext context, IBaseMessage message)

 

Mar 4, 2010 at 4:38 AM

How are your Business Rules configured? What are you settting the Action values to inside the Rules?

Mar 4, 2010 at 8:34 AM

I've tried a couple of really simple rules that only sets the Itinerary name and nothing else (restarted host instances after each policy deploy/test)

[Version 1.0] IF: 1 equals 1 and Action: Set Itinerary Name TestItinerary

[Version 1.1] IF: MessageContextFactRetriever.GetItem(PartyName, http://schemas.microsoft.com/BizTalk/2003/messagetracking-properties) equals [ResolvedPartyName] Action: Set Itinerary Name TestItinerary

I've also tried using a non existing policy name "FooBar" in the Itinerary Select configuration to see if I could get a different exception or something to verify if the policy is beeing called or not, this returned the same exception as the others. 

Switching the moniker in the Itinerary Select configuration from BRE.EXT to BRI returns either my Itineray from rule [Version 1.0]  above or expected error "No versions of ruleset "FooBar" are deployed" when using a non-existing policy name.

Mar 4, 2010 at 12:50 PM
Edited Mar 4, 2010 at 3:11 PM

Problem solved... the BRE_Resolver provider is not configured properly in the esb.config by the installer. The type name for the resolver should read Tellago.SOA.ESB.Extensions.BRE_ResolverProvider not Tellago.SOA.ESB.Extensions.Resolvers.BRE_ResolverProvider

To fix this change the BRE_ResolverProvider typeAlias element under <configuration><esb.resolver><typeAliases>

change from: <typeAlias alias="BRE_ResolverProvider" type="Tellago.SOA.ESB.Extensions.Resolvers.BRE_ResolverProvider, Tellago.SOA.ESB.Extensions.Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b01aa156b4424a13" />

change to: <typeAlias alias="BRE_ResolverProvider" type="Tellago.SOA.ESB.Extensions.BRE_ResolverProvider, Tellago.SOA.ESB.Extensions.Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b01aa156b4424a13" />

cheers

/Henrik

Mar 4, 2010 at 3:01 PM

Thanks I'll make that change...

 

Oct 14, 2011 at 8:19 AM

hello ,

 

I am trying to invoke an itinerary  by having "BRE.EXT:\\policy=TestPolicy13;useMsg=true;version=1.0;recognizeMessageFormat=true;useMsgCtxt=true;msgCtxtValues=;" as my resolver connection string in the ESB itinerary selector pipeline  component of itinearySelectRecieveXML pipeline . 

 Condition in my rule  is seeing wether an XML field is equal to a constant string value and in action part I am having "Set Itinerary Name ABC".

   I am facing the simiar problem that you have mentioned in the first post of this discussion . As suggested by you , I changed <typeAlias alias="BRE_ResolverProvider" type="Tellago.SOA.ESB.Extensions.BRE_ResolverProvider, Tellago.SOA.ESB.Extensions.Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b01aa156b4424a13" /> to <typeAlias alias="BRE_ResolverProvider" type="Tellago.SOA.ESB.Extensions.BRE_ResolverProvider, Tellago.SOA.ESB.Extensions.Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b01aa156b4424a13" /> . Even now I am facing the same problem(Exception has been thrown by the target of an invocation.).

Kindly help me . Thanks in advance .

 

 

 

 

Oct 14, 2011 at 11:48 AM

Trivial check first... are you using the latest version and have you restarted your host instances?

Secondly, the namespace for the BRE_ResolveProvider has changed a bit over time and my post was regarding an old version. The current namespace and type name is Tellago.SOA.ESB.Extensions.Resolvers.Bre.BRE_ResolveProvider, you can verify that using Reflector or Object Browser in VS. Try using this typealias instead

<typeAlias alias="BRE_ResolverProvider" type="Tellago.SOA.ESB.Extensions.Resolvers.Bre.BRE_ResolverProvider, Tellago.SOA.ESB.Extensions.Library, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b01aa156b4424a13" />

cheers
/Henrik

 

Oct 20, 2011 at 8:06 AM
Edited Oct 20, 2011 at 8:31 AM

HI,

I've installed Tellago SOA ESB Extenstions v0.4 extensions on a development box with VS2008, Win2008 Std SP2 32-bit with BTS2009 and ESB Toolkit 2.0 .

I've tried using the type-alias you mentioned .. But I am getting the same error .. 

I tried out few more things which are mentioned below :

 

 

   I am trying to invoke an itinerary from a receive port location through a BRE resolver(as shown in the following diagram).

The  value of resolver connection string is “BRI:\\policy=TestPolicy21;useMsg=true;recognizeMessageFormat=true;”.

 

 

The policy that I am invoking looks like this:

 

 IF: MessageContextFactRetriever.GetItem(Action, http://schemas.microsoft.com/BizTalk/2003/SOAPHeader) equals brazil Action: Set Itinerary Name BBB

When I drop in my message in the input folder the error that I am getting is:
 

The complete error message looks like this:
Procedure or function 'Itinerary_getitinerary' expects parameter '@name', which was not supplied.

Source: Microsoft.Practices.ESB.Resolver.ResolverMgr

Method: System.Collections.Generic.Dictionary`2[System.String,System.String] Resolve(Microsoft.Practices.ESB.Resolver.ResolverInfo, Microsoft.BizTalk.Message.Interop.IBaseMessage, Microsoft.BizTalk.Component.Interop.IPipelineContext)

Error Source: .Net SqlClient Data Provider

Error TargetSite: Void OnError(System.Data.SqlClient.SqlException, Boolean) 

Error StackTrace:    at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection)
   at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj)
   at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj)
   at System.Data.SqlClient.SqlDataReader.ConsumeMetaData()
   at System.Data.SqlClient.SqlDataReader.get_MetaData()
   at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString)
   at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result)
   at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method)
   at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior)
   at Microsoft.Practices.ESB.Resolver.Itinerary.DataAccess.SqlRepositoryProvider.InternalGetItinerary(String name, Nullable`1 majorVersion, Nullable`1 minorVersion)
   at Microsoft.Practices.ESB.Resolver.Itinerary.DataAccess.SqlRepositoryProvider.GetItinerary(String name)
   at Microsoft.Practices.ESB.Resolver.Itinerary.Facts.ItineraryFactTranslator.TranslateFact(Object[] facts, Dictionary`2 factDictionary)
   at Microsoft.Practices.ESB.Resolver.Itinerary.BREItineraryResolverContainer.ResolveRules(String config, String resolver, XmlDocument message, Resolution resolution, BRE bre, List`1 factList)
   at Microsoft.Practices.ESB.Resolver.Itinerary.BREItineraryResolverContainer.Microsoft.Practices.ESB.Resolver.IResolveProvider.Resolve(String config, String resolver, IBaseMessage message, IPipelineContext pipelineContext)
   at Microsoft.Practices.ESB.Resolver.Unity.ResolveProvider.Resolve(String config, String resolver, IBaseMessage message, IPipelineContext pipelineContext)
   at Microsoft.Practices.ESB.Resolver.ResolverMgr.Resolve(ResolverInfo info, IBaseMessage message, IPipelineContext pipelineContext)


However when I used the policy in which the condition is “IF 1  is equal to 1” , the itinerary was successfully invoked . Diagram of the policy is shown in the figure below :
 
From the above two instances we can easily make out that the problem is in the ‘condition’ part of the policy (In other words the fact that we are providing).
Hence I tried a simple scenario . I built a class which had one static variable(GetMaxAllowed)  and the value is initialized to "abc"and added the DLL in to the GAC.


I used the ‘GetMaxAllowed’ variable in my policy as shown  below  :
IF: Class1.GetMaxAllowed is equal to strVlaue
ACTION: SET ITINERARY NAME XYZ
 

I was very sure that this policy would work(‘strVlaue’ is the vocabulaty that I created and the value is “abc” and the data type is System.string . The value of Class1.GetMaxAllowed is also “abc” ) .

But , I got the same error when I dropped my message in the input folder(Procedure or function 'Itinerary_getitinerary' expects parameter '@name', which was not supplied) .


The point I want to make is that , no matter what fact that I provide in the condition part of the policy except for “1 is equal to 1” or similar sort of conditions , the condition will fail and I would get the error as shown in the figure 3 .

 


Regards,
NARENDRA

 

 

 

 


Oct 20, 2011 at 9:30 AM

Hi

ok, so you've switched to BRI to testing the policy, ok... I've asked Tellago to add the correct typeAlias string for version 0.4 in this discussion.

Regarding your BRI-problems or rather the policy... when you are usint the BRI-resolver you can not use the MessageContextFactRetriever from BRE.EXT since BRI doesn't add the context dictionary. You can use the ESB Toolkit provided dictionary with message context-properties though. This explains your first error...

The second problem when calling static methods you'll have to enable StaticSupport in Rules Engine for that to work, see http://biztalktalk.wordpress.com/2011/08/16/calling-helper-methods-from-the-business-rules-engine/

Btw. run a DebugView in parallell when you're testing, that will give you som more details of the inner workings in ESB Toolkit etc.

cheers
/Henrik

Oct 20, 2011 at 2:25 PM

Hello,

Ur idea to enable static support in Rules Engine has helped me . My solution is working now .Thank you very much.

 Since I was not able to use the context property of my message directly in a BRE rule directly , I have tried out few things .Please tell me wether I am correct in my approach.

  • I have used an intermediate schema . My custom pipeline component in the decode stage of the receive pipeline writes the value of context to a field in my intermediate schema .
  •   I have written static  .NET method (which  would retrieve the value of  field from intermediate schema )  and  this method is used in my rule which eventually decides whether the itinerary should be invoked or not .(IF:Class1.ReturnField is equal to ABC ACTION:Set Itinerary Name QQQ)

 

Regards,

NARENDRA

 

 

 

 

 

 

 

 

Oct 20, 2011 at 3:55 PM

Hi

please standby for a response from Tellago regarding the BRE.EXT setting in ESB.Config, with BRE.EXT working you should be able to use your initial and most direct approach:

I assume that the value your expecting to use to resolve the Itinerary is only available in the message context so your other approach using an intermediate schema where you have pushed the context value into the message is ok, you can consider to use a Vocuabulary definition with a "Xml Document Element or Attribute" i.e. xpath lookup instead of a static class method doing the same thing. Please note that the RecognizeMessageFormat setting determines the Document Type to use in the the dictionay, if it is set to false then use Microsoft.Practices.ESB.ResolveProviderMessage, see http://social.msdn.microsoft.com/Forums/en-AU/biztalkesb/thread/b597c320-9085-4a7c-88e1-784068b60add for details.

I normally use an approach with Party Resolution component preceeding the Itinerary resolver (custom component from the BizTalk SDK) to lookup sender and reciver from Global Parties using the alias table there and then using the combination of Receiver and (optionally) Sender and MessageType when resolving the itinerary. This is a more generic approach commonly used in B2B/EAI scenarios.

cheers
/Henrik