ESB 2.1 Loading Type Issue !! Deployed Tested MAP ..was not a valid map type

Question

Dear gurus,

  

 I have map which need to be executed from ESB 2.1, the same map and schema types are being called from BizTalk without any issues but when I am trying the same on ESB it is throwing an following exception.

 

The type for <TypeName>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=6f835a3699b441a6 was not a valid map type.

 

Source: Microsoft.Practices.ESB.PipelineComponents.Dispatcher

 

Method: Microsoft.BizTalk.Message.Interop.IBaseMessage Execute

 

Seems to be ESB trying to load the map type using reflection and it’s not getting loaded  due to  some reasons.

 

-Rajesh Gorla.

Answer 1

Hello,

I am also facing the similar issue.

While testing the map locally it processes without any error, But when trying using ESB shows error as above. Following is the full error text for your reference.

The type for <TypeName>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=1161fcce971d2bd1 was not a valid map type.

Source: Microsoft.Practices.ESB.PipelineComponents.Dispatcher

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

Error Source: Microsoft.Practices.ESB.Itinerary.Services

Error TargetSite: System.IO.Stream TransformStream(System.IO.Stream, System.String, Boolean, System.String ByRef) 

Error StackTrace:    at Microsoft.Practices.ESB.Itinerary.Services.TransformationService.TransformStream(Stream stream, String mapName, Boolean validate, String& messageType)
   at Microsoft.Practices.ESB.Itinerary.Services.TransformationService.ExecuteTransform(IPipelineContext context, IBaseMessage msg, String mapNameOrResolverString, Boolean validateSource)
   at MyCore.Library.TransformAndRouteService.transform(IPipelineContext context, IBaseMessage msg, String resolverString)
   at MyCore.Library.TransformAndRouteService.Execute(IPipelineContext context, IBaseMessage msg, String resolverString, IItineraryStep step)
   at Microsoft.Practices.ESB.PipelineComponents.Dispatcher.Execute(IPipelineContext context, IBaseMessage msg)

Answer 2

Please double check whether fully qualified map name is specified correctly or not (including space after ","). You can find some more information about this here and here .

---

Please mark it as answer by clicking on "Propose As Answer", if it helps

Answer 3

Hello,

• Please check that the assembly containing your map has been deployed correctly and is present in the GAC;
• Please verify that the type name you re provided to the mapper is correctly written :

   AssemblyFullName.MapName, AssemblyFullname, Version=1.0.0.0, Culture=neutral, PublicToken=yourkey 

Double check the type you re providing with your assembly infos. From your description, it seems to me your Typename is not complete.

The ESB default ESBFaultPipeline contains a correct maptype reference in the ESB Transform Component.

Hope this helps.

---

Hautecoeur F. MCTS Biztalk 2006 MCTS WCF 3.5, 4.0

Answer 4

Are you on 64bit?

Is your assembly Gac'd in the correct places? there's a new GAC for .Net 4.0 assemblies vs .Net previous versions. I usually Gac BizTalk assemblies in both places, but I haven't read up specifically on which is absolutely needed.

 

The easiest way to Gac to both is the use the .net 4.0 GAC util from the Win7.0a\sdk .net 4.0 folder. Then to gac for BizTalk, use the "Add BizTalk Assembly" from the BizTalk Admin console, and select the also Add to Gac on add assembly reference...

 

HTH

---

MCT, MCSD.NET, BizTalk TS

Answer 5

Yes i am running on 64 bit win 2008 r2

Confused!!! I have done GAC 4.0 older / new versions  but no luck, still having the same issue, i would like to debug the pipeline component dispatcher but no source is available..i did try the same scenario on ESB 2.0 , BizTalk 2009 worked well no issues...

hmmm...:(( scared !!

-Rajesh Gorla.

---

-Rajesh Gorla

Answer 6

It's the location of where your files are GAC'd. That's the issue.

 

The easiest way to garuantee that the files are Gac'd in the correct location for BizTalk is to use the BizTalk Admin Console, and add an assembly to the Application, checking the Gac on add option.

 

Please check out this post: http://social.msdn.microsoft.com/Forums/en-NZ/biztalkesb/thread/2a1141a9-35df-4fdd-a6d2-c2fe5fe0455c

and this post:

http://stackoverflow.com/questions/2660355/net-4-0-has-a-new-gac-why

 

---

MCT, MCSD.NET, BizTalk TS

Answer 7

Guys I went ahead a step.

I think GAC is not a problem at all!!

now i would be able to call maps on esb in one scenario but it doesn’t solve my purpose, i am sure there is something with the security it doesn’t let esb to load the type. there is some trick i am not sure what it is !! Here the info

i have a message published to message box with the itinerary select pipeline using File adapter it worked !! and

i have taken the same schema exposed as web service and on receive location / receive pipeline I have used the same configuration what I used in above scenario, it doesn’t work and the errors remain same .. “Not a valid map type.”

The only difference i have seen in both cases is in-process host (file adapter) and isolated host (wcf ws-http adapter),so i suspect when the message is coming from isolated host it has to have enough permissions to load the types ..It still loads the itinerary and executes the first step but i didn’t not see any message in message box, since the pipeline process is not getting completed.

Finally let me tell you what my itinerary does, when a message arrives on bus it resolves transform type for message and transforms to destination request type, resolves the end point to send to dynamic port where my off ramp is configured.

any suggestions!!

 

 

 

 

---

-Rajesh Gorla

Answer 8

Ok, back to the basics...

 

Maps are loaded and determined by their source message type, unless you dynamically determine the map by a resolver by specifying the full name of the map/assmbly/pk/culture etc.

Help me out here...

In your scenario 1, you have File Adapter -> Itin Select XML pipeline -> Success

In you scenario 2, you have IIS -> WCF adapter -> Itin Select XML pipeline -> Fail to find map...

Is the above correct?

 

So Scenario 2 you have to look at everything that's going on, You have a SOAP message coming in- thus the message type will not necessarily be the same as in Scenario 1, you can try using the Itinerary Select Passthrough pipeline, to see what you get. I'd suspect that it would work, as you're not going to get a message type, but due to the Itinerary you'd force it to use the map through the resolution.

 

HTH

---

MCT, MCSD.NET, BizTalk TS

Answer 9

Ok.

i have used the fully qualified map name in so it should load, source message is publishing to message box looks alrite since i have the same scenario without esb up and running ..

I have tried with follwing pipelines

ItinerarySelectReceivePassthrough - <Type>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=39eeccd36c2c4b31 was not a valid map type.

ItinerarySelectReceiveXml  - Verify the schema for this document specification is deployed and is in the Global Assembly Cache.

ItinerarySelectReceive -  <Type>, Version=1.0.0.0, Culture=neutral, PublicKeyToken=39eeccd36c2c4b31 was not a valid map type.

My Itinerary looks like:

<Itinerary xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" uuid="" beginTime="" completeTime="" state="Pending" isRequestResponse="false" servicecount="3" name="Company" version="1.0" xmlns="http://schemas.microsoft.biztalk.practices.esb.com/itinerary">

  <BizTalkSegment interchangeId="" epmRRCorrelationToken="" receiveInstanceId="" messageId="" xmlns="" />

  <ServiceInstance name="Microsoft.Practices.ESB.Services.Transform" type="Messaging" state="Pending" position="0" isRequestResponse="false" xmlns="" />

- <Services xmlns="">

  <Service uuid="cfbe36c5-d85c-44e9-9549-4a7abf2106c5" beginTime="" completeTime="" name="Microsoft.Practices.ESB.Services.Transform" type="Messaging" state="Pending" isRequestResponse="false" position="0" serviceInstanceId="" stage="receiveInbound" id="b5bc8b9f0cc54aa69fd00a386658bc82" nextId="9796468aab0a49d88983f7519561ca17" businessName="Transfrom_Company_SOAP_Message" />

  </Services>

- <Services xmlns="">

  <Service uuid="6a594d80-91f7-4e10-a203-b3c999b0f55e" beginTime="" completeTime="" name="Microsoft.Practices.ESB.Services.Routing" type="Messaging" state="Pending" isRequestResponse="false" position="1" serviceInstanceId="" stage="receiveInbound" id="9796468aab0a49d88983f7519561ca17" nextId="cef6bb8cfe7a4693aa3772ae9ab143bc" businessName="Route_Company_Message" />

  </Services>

- <Services xmlns="">

  <Service uuid="79dc570bd5cc491cb51d62ba8d74b0ac" beginTime="" completeTime="" name="Microsoft.Practices.ESB.Services.Routing" type="Messaging" state="Pending" isRequestResponse="false" position="2" serviceInstanceId="" stage="sendTransmit" id="cef6bb8cfe7a4693aa3772ae9ab143bc" nextId="00000000000000000000000000000000" businessName="Send2_OffRamp" />

  </Services>

- <ResolverGroups xmlns="">

  <Resolvers serviceId="Microsoft.Practices.ESB.Services.Transform0"><![CDATA[STATIC:\\transportType=;transportLocation=;action=;endpointConfig=;jaxRpcResponse=false;messageExchangePattern=;targetNamespace=;transformType=ESB.Maps.EnterpriseCompany_to_SOAP_Company,ESB.Maps, Version=1.0.0.0, Culture=neutral, PublicKeyToken=39eeccd36c2c4b31;]]></Resolvers>

  <Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing1"><![CDATA[STATIC:\\transportType=WCF-BasicHttp;transportLocation=http://localhost:88/OrderEntry/Company;action=http://tempuri.org/CompanyService/CompanySaved;endpointConfig=;jaxRpcResponse=false;messageExchangePattern=One-Way;targetNamespace=http://tempuri.org/;transformType=;]]></Resolvers>

  <Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing 2" />

  </ResolverGroups>

  </Itinerary>

---

-Rajesh Gorla

Answer 10

From what I can tell there's only one issue in your itinerary:

3rd to last line:

<Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing 2" />

 

should be:

<Resolvers serviceId="Microsoft.Practices.ESB.Services.Routing2" />

The ServiceId should not contain spaces. It should be "...Routing2" not "...Routing 2". Is this copy and pasted exactly? Or is this just a typo?

 

This by the way does not appear to have anything to do with your errors however...

HTH

---

MCT, MCSD.NET, BizTalk TS

Answer 11

Some more things to check and do:

1. Use the WCF ResolverService to test your ResolverConfiguration string and message.

2. Use the Transformation WCF Service to Unit test your map. This will let you know if the map works by passing in the Fully Qualified name of the map. and the message As the ESB would do it, because you said it already works in BizTalk Normally. This service will return the result of your transformed message, if it can find the map.

3. Verify that there are not two maps installed in BizTalk, such as the same map, in the same assembly version, in two different BizTalk Applications. This will cause a ambiguity issue when trying to resolve which map.

 

*Note: we used these services to build unit tests for our ESB implementation, maybe this can help in trouble shooting your issues.

---

MCT, MCSD.NET, BizTalk TS

Answer 12

I am facing the exactly same issue.....Have you find any solution

Answer 13

 

I have found the resolution of this issue.

Please change the version of your new WCF service's application pool from 2.0 to 4.0

Everything will work smoothly

 

 

 

 

Answer 14

I am sorry for not closing the post,

i may had issue with my virtual or  the version upgrade from 2009 ESB 2.0 to 2010 esb 2.1,  so finally i get rid of issue by doing clean install.

so i am not sure what was really causing the problem.

virtual box ? version upgrade ? solution upgrade from 3.5 to 4.0 framework.

---

-Rajesh Gorla

Answer 15

Hi,

I will go with Shagun as changing version of App Pool to 4.0 has resolved my issue as well.

Thanks for the solution.

---

Ayaz Shaikh