Here is one cause of the error below. In this case, a fellow developer GAC’ed the .DLL in the Deployment/bin instead of the Development/bin. There was a .DLL in the Deployment/bin, but it was much older, and didn’t have the specific orchestration being called for.
Failed while creating a Your.ProjectName.YourOrchestrationName service.
Exception type: ServiceCreationException
The following is a stack trace that identifies the location where the exception occured
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._serviceCreator(Guid& instanceId, Object objCurrMsg)
at Microsoft.XLANGs.Core.ResourceContainer._allocateResource(Guid& key, UInt32 hashKey, ResourceCreator resCreator, Object creationContext)
at Microsoft.XLANGs.Core.ResourceContainer.Dispense(Guid& key, ResourceCreator resCreator, Object creationContext)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._dispenseService(Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._tryReceiveOneMessage(Boolean& loggedError, Guid& instanceId, IBTMessage currMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession._receiveOneMessage(Guid& instanceId, Guid& serviceId, IBTMessage currentMsg)
at Microsoft.BizTalk.XLANGs.BTXEngine.BTXSession.ReceiveMessages(IBTMessage messages, Int32 firstIdx, Int32 count)
at Microsoft.BizTalk.XLANGs.BTXEngine.AppDomains.AppDomainRoot.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object objMsg)
at Microsoft.XLANGs.BizTalk.CrossProcess.AppDomainStubProxy.Microsoft.XLANGs.BizTalk.ProcessInterface.IAppDomainStub.ReceiveMessages(Object msgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg, Int32 methodPtr, Boolean fExecuteInContext)
at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception: System.ServiceModel.CommunicationException: There was an error while trying to serialize parameter http://tempuri.org/:ExportValuationPolicyNumberResult. The InnerException message was ‘Type ‘TFBIC.RCT.WCFWebServices.ExpressLync.MainStreetValuation’ with data contract name ‘MainStreetValuation:http://schemas.datacontract.org/2004/07/TFBIC.RCT.WCFWebServices.ExpressLync’ is not expected. Add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.’. Please see InnerException for more details. —> System.Runtime.Serialization.SerializationException: Type ‘TFBIC.RCT.WCFWebServices.ExpressLync.MainStreetValuation’ with data contract name ‘MainStreetValuation:http://schemas.datacontract.org/2004/07/TFBIC.RCT.WCFWebServices.ExpressLync’ is not expected. Add any types not known statically to the list of known types – for example, by using the KnownTypeAttribute attribute or by adding them to the list of known types passed to DataContractSerializer.
1. Manually create a proxy to the WCF Service from the command line like so:
svcutil /serializer:XmlSerializer http://localhost:46122/ValuationService.svc
2. Add the [XmlSerializerFormat] to your ServiceContract on the WCF Service
By doing this, we force our WCF Service to use the XmlSerializer rather than the default DataContractSerializer. Note: you?ll need to call the WCF service from you new proxy in your sample code.
When using HIP (CICS Host-Initiated-Processing) [part of Host Integration Services – or HIS] – you might get the error “Select Error Occurred”. This seemed to happen to me when I was trying to pass a null value back to the HIP (and therefore CICS). It seems to want to have all the fields set to some value other than null. Unfortunately, it doesn’t tell you the field that is causing the problem.
With other errors, sometimes you will get an Event Log message that is more helpful. For example, if CICS tries to send a number that is too large for the .NET type, you will get a message like this:
Event Type: Error
Event Source: HIP Service
Event Category: (7)
Event ID: 815
Time: 1:00:29 PM
(815) A Transaction Integrator flow control module is reporting a failure when converting client user data.
HIP Application: RCTGetReplacementCost
Error Description: (1507) The magnitude of a sending field exceeds that allowed for a receiving field in RqstEstimateNumber in GetReplacementCost.
The size of the number is too large to be placed into the resulting data type. Check for a client application error and correct. If the client application is correct consider modifying the data conversion mapping so that the parameter is converted to a data type capable of accepting the numeric value.
An error has occurred when converting input user data.
Verify that the client program is sending the correct data and that the correct HIP mappings have been administered. Make sure that the Transaction Integrator service has been properly deployed and administered and that the HIP runtime environment has been installed on the system on which the failure occurred. If the problem persists contact Microsoft support.
This can happen if COBOL has for example PIC S9(10), and .NET has an integer. Entering 1111111111 in the number “fits”, but entering 2222222222 does not.
Of course, check your action first. It could be misspelled or mistyped.
What can happen is that your BizTalk works fine with a WCF web service,
but then you move the WCF service to a different machine and get the error below.
Apparently, this only happens when the different machine is in a different domain.
<s:Reason><s:Text xml:lang="en-US">The message could not be processed.
<br />This is<br />
most likely because the action 'http://YourService/IYourInterface/YourMethod' is incorrect or <br />because the message contains an invalid or expired security context token or because there <br />is a mismatch between bindings. The security context token would be invalid if the service <br />aborted the channel due to inactivity. To prevent the service from aborting idle sessions <br />prematurely increase the Receive timeout on the service endpoint's binding.</s:Text>
Add the code below to the web.config for your WCF web service.
To see how to run the full server side trace and view the output, please see this article. http://biztalk-training.com/readarticle.php?article_id=20
In my specific case, I was calling a WCF service that used LINQ to retrieve data from a database and return as a LIST of LINQ objects. When I ran 85 records, it would run, but when I ran 90 it would not, so I knew the issue was size related.
it turns out that the server side trace gave me the more specific error:
System.Runtime.Serialization.SerializationException: Maximum number of items that can be serialized or deserialized in an object graph is ‘65536’.
Note: this is after I already bumped up all the timeouts and the maxBufferPoolSize and the maxReceivedMessage size.
If more than one borrower occurs under “Borrowers”, we get the following error:
A message sent to adapter “FILE” on send port “YourSendPortName” with URI “c:BiztalkDemosYourSubFolder%SourceFileName%” is suspended.
Error details: Unable to read the stream produced by the pipeline.
Details: Cannot find definition for the input: BORROWER
The m ap w as using a Logical-If and a Value-Flattening Functoid.
The incoming test data was auto-generated by doing a right-click generate on a schema,
thus we had duplicate children (Borrowers) in the incoming data file.
By changing the test data, and setting various flags so that the Logical-If functoid only selected one child amongst the children, the problem went away.
This error was only detected when running via the pipeline. The error did not occur when doing a “Test Map” inside Visual Studio.