Running Instance keeps being "Active" without showing Action (WCF-Custom Sendport)

I stumpled over the following phenomenon that an instance in BizTalk 2013 kept running (in active state) although it did not do anything. You could see in the Webserver logs that the session was not running any longer. When I run the same Webservice with SoapUI, I could see that the Webservice responded with a timeout message (http 500) after 15 minutes:

500 Connection timed out

---

Wed Nov 12 16:07:54 2014

BizTalk must have received the same, but somehow did not suspend the message. 

Did anyone else run into the same error, or could give me any hint?

FileNotFoundException of Microsoft.BizTalk.Interop.SSOClient.dll, Version=5.0.1.0

I am migrating from BizTalk 2013 to R2 and in doing so the BizTalk Development Framework missed the assembly Microsoft.BizTalk.Interop.SSOClient from version 5.0.1.0. I could see that newer versions were installed in the .net 4.0 GAC.

So if you run into the same problem, you could download the BizTalk Development Framework sourcode and could manually put the missing assembly into the .net 2.0 GAC

Biztalk WCF SAP Exception "The parameter Program Id required for SAP Inbound Handler was not specified"

If you get this exception in the WCF SAP Receive Location

The Messaging Engine failed to add a receive location "Scandlines_IDoc_Handler" with URL "sap://CLIENT=007;LANG=EN;@a/SAP.SE.RV.ER/00?ListenerGwServ=sapgw00;ListenerGwHost=SAP.SE.RV.ER;ListenerProgramId=PROGRAMID;RfcSdkTrace=True;AbapDebug=False" to the adapter "WCF-Custom". Reason: "Microsoft.ServiceModel.Channels.Common.ConnectionException: The parameter Program Id required for SAP Inbound Handler was not specified.
   at Microsoft.Adapters.SAP.SAPInboundContract.StartListener(String[] listenerActions, TimeSpan timeout)

it might, of course, be because the Program ID was not specified. However, in our case, we had not created the right SAP Connection String. All paramter have to be joined with "&" character. So if you run into the same error, look carefully at the Connection string and also at the spelling of the parameters.

XTransformationFailureException.. or Attribute and namespace nodes cannot be added to the parent element after a text, comment, pi, or sub-element node has already been added.

I just met this fine error after a migration of BizTalk2006 maps to 2013. It is strictly connected to the use of XslCompiledTransform which is now used since BizTalk 2013.

In my case it occurred whenever an depended father field was filled with NIL.
See the example here:

Quick solution was removing the NIL value and just apply the boolean value to the father element

BizTalk XmlException: "'Text' is an invalid XmlNodeType. Line 1, position 1"

If you run into this error during runtime:

A message sent to adapter "WCF-Custom" on send port "SapInvoiceExport" with URI "sap://CLIENT=007;LANG=EN;@a/SAP-SERVER/00?GWSERV=sapgw00&RfcSdkTrace=False&AbapDebug=False" is suspended.
 Error details: System.Xml.XmlException: 'Text' is an invalid XmlNodeType. Line 1, position 1.
   at System.Xml.XmlReader.ReadStartElement(String name)
   at Microsoft.BizTalk.Adapter.Wcf.ComponentModel.IdentityElementSurrogate.ReadXml(XmlReader reader)
   at Microsoft.BizTalk.Adapter.Wcf.ComponentModel.IdentityElementSurrogate.set_ConfigXml(String value)
   at Microsoft.BizTalk.Adapter.Wcf.Config.CustomTLConfig.CreateEndpointAddress()
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfClient`2.InitializeValues(IBaseMessage message)
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfTransmitter`2.GetClientFromCache(String spid, IBaseMessage message)
   at Microsoft.BizTalk.Adapter.Wcf.Runtime.WcfAsyncBatch`2.BatchWorker(List`1 messages)
 MessageId:  {E62F2F57-1727-40A7-81DC-8DF797250933}
 InstanceID: {E59F2C86-D2A7-4A57-B6B0-7C3995676E3A}

... then your WCF Send Port Configuration might have screwed up. You can verify this, if the "Send Port Configuration Wizard" breaks with this error when you press the "Edit Endpoint Identity" button or when you try to export the configuration. The Endpoint Identity itself shows some sort of stars:

 

Solution (July 7, 2014): I imported the binding files with <Password vt="1">pwd<Password><Identity vt="1" />. Since vt contains the type (and format) of the element, it got somehow puzzled. So either use vt="8" or just remove the <Identity> element if you do not need it.

However, the same error can occur also with other mistakes in the Custom props, for example wrong passwords or escaping errors (for example, a non-escaped ">"). Thanks, Christian, for the information!

Biztalk/VS Error Message "non-readonly field property access is limited to distinguished fields on class-based messages"

Do you run into the following error while building your Biztalk project?

Non-readonly field property access is limited to distinguished fields on class-based messages.

Visual Studio seems to misinterpret your property access to the XmlDocument message, for example with MSG.DocumentElement.LocalName. It assumes that you want to access a distinguished field, which is not allowed here.

Mahesh explained this error on MSDN - it comes from the installation of Hotfix 2851429 in CU2. According to Microsoft, it will be fixed with CU3; if you do not want to wait, you should contact Microsoft Support.

Until then, the only solution that helped me was to un-install the CU2.

Here the screenshot of the error:

UPDATE on July 8th, 2014: The issue is solved in BizTalk 2013 R2.

Biztalk FILE Send Port throws "The system cannot find the file specified"

If you receive this exception in BizTalk

A message sent to adapter "FILE" on send port "SENDPORT_FILE" with URI "\\ABC\PATH\%MessageID%.xml" is suspended. 
Error details: The system cannot find the file specified. (Exception from HRESULT: 0x80070002)
MessageId:  {5EC92559-C6E3-490C-A1D4-981D154BA126}
InstanceID: {4FF0F3DE-9A4C-4ECE-8C5A-98B34C78701E}

the reason could be that BizTalk does not find the assembly during runtime in the GAC, although it was there. In my case, I had to create the assembly in Development mode instead of instead of and then BizTalk could find the assembly.

SAP WCF MetadataException "RFC IDOC_INBOUND_ASYNCHRONOUSM could not be resolved against SAP"

If you run into this error

The adapter "WCF-Custom" raised an error message. Details "Microsoft.ServiceModel.Channels.Common.MetadataException: RFC IDOC_INBOUND_ASYNCHRONOUSM could not be resolved against SAP system because its metadata could not be obtained. ---> Microsoft.Adapters.SAP.RFCException: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=FU_NOT_FOUND.  AdapterErrorMessage=An error occurred while determining the function interface of the RFC IDOC_INBOUND_ASYNCHRONOUSM.

then you might use a the new WCF SAP adapter with a Non-Unicode RFC Destination. The BizTalk Adapter Pack 2013 does not seem to be compatible with Non-Unicode RFC as it was before. The only solution seems to be to create a new RFC Destination in SAP.

WCF SAP Exception ArgumentNullException "Value cannot be null."

If you run into this error:

The adapter failed to transmit message going to send port "SAP_NokasPettyCashImport.SendToSap" with URL "sap://CLIENT=007;LANG=EN;@A/XXX/00?GWSERV=XXX&RfcSdkTrace=True&AbapDebug=False". It will be retransmitted after the retry interval specified for this Send Port. Details:"System.ArgumentNullException: Value cannot be null.
Parameter name: key

....check whether you really put in an Action in the WCF SAP Sendport (or the Action property arrived at the Sendport).

BizTalk Adapter Pack Updates

Just to not forget: Microsoft has a useful list of all updates concerning BizTalk. Please do not forget (like it happened to me) to scroll down until you reach the BizTalk Adapter Pack updates. They are published separately.

Please open the BizTalk Update Site with Firefox - I'm not joking, IE 10 was hiding the Adapter Pack 2013 updates due to an html error.

WCF SAP Adapter XmlReaderParsingException

If you run into this exception:

A message sent to adapter "WCF-Custom" on send port "SENDPORT" with URI "sap://CLIENT=123;LANG=EN;@a/ABC/00?GWSERV=DEF&RfcSdkTrace=True&AbapDebug=False" is suspended.
 Error details: Microsoft.ServiceModel.Channels.Common.XmlReaderParsingException: The length of the value for the field exceeds the allowed value. Value: 4  Field: TDSPRAS Allowed value: 2

then you should check the IDoc-XML carefully. Since the generated XSD itself does not necessarily check for maxLength (it might only define xsd:string), the IDoc-XML might successfully validate against the schema. However, during run-time the WCF SAP adapter checks the field length against the IDoc specification and fails.

You can find the real field length actually in the flat file attribute pos_length.

Also keep in mind that the length value is doubled (at least, in our case). The exception message says that a length of 2 is allowed, but actually only 1 is allowed. I suspect that there is some encoding reason behind.

Solution: You can enrich the generated XSD by using all pos_length values in MaxLength. This way the error will be seen earlier.

BTW, if you transfer IDoc as a flat file and thus use the Flat file-Assembler, you won't run into that problem since the assembler just cuts the overlength. ;-)

SAP-Adapter Error "The segment or group definition E2IDKU5 was not found in the IDoc metadata."

During runtime, we received the following error from the WCF SAP adapter:

Microsoft.ServiceModel.Channels.Common.XmlReaderGenerationException ist aufgetreten.
  HResult=-2146233087
  Message=The segment or group definition E2IDKU5 was not found in the IDoc metadata. The UniqueId of the IDoc type is: IDOCTYP/3/PEXR2002//701. For Receive operations, the SAP adapter does not support unreleased segments.
  Source=Microsoft.Adapters.SAP
  StackTrace:
       bei Microsoft.Adapters.SAP.TypedIdocBodyWriter.OnWriteBodyContents(XmlDictionaryWriter writer)

The reason was that the IDoc contained the element name E2IDKU5 although its segment definition was E2IDKU5001.

So, whenever you run into a similar message, it's worth to check the SAP transaction WE60 to check the segment definition of the element.
 

Typical Problems Making SAP BAPI Calls

This is an uncomplete list of typical problems when you run BAPI calls.

1. If you get an empty result from SAP, you have to pass a stub of the result that you expect (read http://blogs.msdn.com/b/adapters/archive/2008/01/10/when-i-execute-bapis-i-don-t-get-back-any-data-help.aspx for more information).

2. If you get this exception

Microsoft.ServiceModel.Channels.Common.XmlReaderGenerationException: An error occurred when trying to convert the byte array [30-00-30-00-30-00-30-00-30-00-30-00-30-00-30-00] of RFCTYPE RFCTYPE_DATE with length 8 and decimals 0 to XML format. Parameter/field name: CLEAR_DATE   Error message: Die Parameter "Year", "Month", und "Day" beschreiben eine nicht darstellbare DateTime.

 you might want to create the Biztalk BAPI schema with enableSafeTyping=true. Also use this option during run-time. You can then use dates in the form of YYYYMMDD.

If you are aware of (1) and (2), a working BAPI Call would be:

<ns0:GETSTATEMENT xmlns:ns0="http://Microsoft.LobServices.Sap/2007/03/Bapi/BUS3007/">
 <ns0:COMPANYCODE>xxx</ns0:COMPANYCODE>
 <ns0:CUSTOMER>xxx</ns0:CUSTOMER>
 <ns0:DATE_FROM>20140101</ns0:DATE_FROM>
 <ns0:DATE_TO>20140505</ns0:DATE_TO>
 <ns0:NOTEDITEMS>X</ns0:NOTEDITEMS>
 <ns0:LINEITEMS />
</ns0:GETSTATEMENT>

Thanks, Mirko!

Read IDocs with WCF-SAP-Adapter that contain Elements that are not attached to a SAP Release

There are basis types that contain elements that are not attached to any release; by design, you cannot retrieve their schema with the Consume Adapter Wizard like it is explained here neither could you get the IDocs on run-time. In both cases, you receive an error like this:
Error while retrieving or generating the WSDL. Adapter message: Details: ErrorCode=RFC_EXCEPTION. ErrorGroup=RFC_ERROR_APPLICATION_EXCEPTION. SapErrorMessage=SEGMENT_UNKNOWN.  AdapterErrorMessage=Error returned by RfcCallReceiveEx while calling RFC: IDOCTYPE_READ_COMPLETE..

When you anyway have to get the IDocs and your SAP colleagues cannot change the basis type's setting, you still can read the IDocs "weakly-typed", i.e. with the setting ReceiveIdocFormat=String.

First, you have to get the general ReceiveIdoc schema:

 

Second, you have to change the setting in the WCF-Adapter and set ReceiveIDocFormat to from "Types" to "String". A good explanation of how to receive idocs in this "raw format" is written by Mustansir and Gordie, as well as on MSDN.

The drawback of this solution is that you now receive the IDocs in a flat file format and no longer in good-readable and handable XML - until you add a flatfile pipeline.

Tipp: Use WE60 in SAP to find the element that is not set to a release! Maybe your SAP administrator can set this element to a release, and then you can retrieve the schema.

Visual Studio's Consume Adapter Wizard does not show the SAP IDoc you search

There are several reasons, if you can't see an SAP IDoc in the "Consume Adapter Wizard"-List.

First, their might be a resitriction in SAP: You could analyse this in se37 calling IDOCTYPE_READ_COMPLETE. Thanks for the help, Patrick!

Second, you might search for a basic type but the wizard only list message types (and one level deeper, its basis type). Thanks, Christian!

Third, the IDoc search in the wizard does not search for basic types, so you really have to find out what message type uses this basic type.

You can find a good explanation on IDoc opertions on MSDN.

Request-Response for WCF-Custom Receive Location Timed Out

In case you get the following error

A request-response for the "WCF-Custom" adapter at receive location "sap://CLIENT=xxx;LANG=DE;@d/ABCDEF?ListenerDest=VWXYZ&RfcSdkTrace=True&AbapDebug=False" has timed out before a response could be delivered.

...then your Receive Location with a WCF-Custom adapter and SAP-Binding run into a time-out while sending the reply to the SAP system. In this case, you might accidently have used a transactional RFC connection, that happens if you use a Request Response Receive Location instead of a One-Way Receive Location (for example, because Visual Studio created you a binding with Request Response RL).

To solive this, you could either use a Request Response RL and send the response by your own, or you simply switch to a One-Way RL.

WCF LOB Adapter Exception "Melden Sie sich mit einem Dialogbenutzer an"

If you receive the folgenden error message in the SAP WCF dialog:

Connecting to the LOB system has failed.

Details: ErrorCode=RFC_OK. ErrorGroup=RFC_ERROR_LOGON_FAILURE. SapErrorMessage=Melden Sie sich mit einem Dialogbenutzer an.  AdapterErrorMessage=..

...you might have set AbapDebug to "true", like I did in my WCF URI "sap://CLIENT=800;LANG=DE;@A/sap.host.de/00?ListenerDest=ABC&ListenerProgramId=DEF&RfcSdkTrace=False&AbapDebug=True"

If you set AbapDebug to "true", you have to log on with a Dialog user.

WCF LOB Adapter Exception: "Connect from SAP gateway to RFC server failed"

If the WCF LOB Adapter Pack receives a RFC_ERROR_COMMUNICATION from SAP saying "Connect from SAP gateway to RFC server failed", you have to double check that all network settings are correct so that send and receive are possible. In our case that NATting of the response did not reach us, while we could track our call successfully on the firewall.
Other reasons might be SAP configuration or missing entries in services file.