none
Biztalk Internal Server Error RRS feed

  • Question

  • Hi

    I am experiencing an error when sending an IDOC message to SAP from BizTalk. The IDOC reaches SAP with no issues however we do not receive the standard GUID response message back and this error is reported by BizTalk - 

    Error Description: An internal server error was encountered while attempting to transmit the message

    We are using the WCF-Custom adapter.

    Has anyone encountered this before?

    Thanks in advance

    Riaz

    Tuesday, October 14, 2014 6:48 AM

Answers

  • Hi All

    Finally found the solution to this one.

    I was not aware that our production environment was split into two instances. After finding that out and looking in the event viewer of the second server I found this error - 

    'There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: "XXX_SEND" URI: "sap://XXXXX" Reason: The document specification <XXX.Schemas.IDOC_ZPREQ03_RESPONSE> from assembly <XXX.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ebeb85b54f9d7ba9> failed to load. Verify the schema for this document specification is deployed and is in the Global Assembly Cache'

    Needless to say I deployed the assemblies to this second server with a bit of effort due to concurrency violation errors but eventually got it done.

    All working fine now :)

    Thanks for the helpful tips.

    Regards

    Riaz

    • Marked as answer by RiazP-MSDN Thursday, December 18, 2014 6:26 AM
    Thursday, December 18, 2014 6:26 AM

All replies

  • What is the pipeline being used at response ? Do you see any suspended messages ? Any additional error details in the event logs?

    Regards &lt;br/&gt; When you see answers and helpful posts,&lt;br/&gt; please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    Tuesday, October 14, 2014 6:50 AM
    Answerer
  • Hi,

    Can you  check the respose type message inside your Orchestration ?

    You can use Fidller to capture the response coming from SAP System and try to validate against your response message .

    Also varify the event log for any additional error .

    Thanks
    Abhishek

    Tuesday, October 14, 2014 7:03 AM
  • Its a Static Solicit-Response port and the receive pipeline is an xml receive pipeline.

    This has always worked until recently. No messages are suspended and there is no additional info on the event logs.

    Tuesday, October 14, 2014 7:30 AM
  • Hi

    The response type message in the orchestration is taken from the schema i downloaded from the SAP system. Its is a simple xml message with one field - the GUID.

    No event log errors.

    I will look into Fiddler now.

    Thanks

    Tuesday, October 14, 2014 7:31 AM
  • Fiddler does not seem to be picking up any traffic from my BizTalk server to SAP.

    Is there anything special i need to configure for this?

    Tuesday, October 14, 2014 8:22 AM
  • You need to confiure the proxy in send port for Fiddler to trace the message flow.

    Read this blog on how to use fiddler.

    http://www.fortuvis.com/blog/using-biztalk-with-fiddler/

    With the error message, there seems to be an error in the destination server in accepting the message. Tracing through the Fiddler with the response shall help you get the exact the messages being shared (in request and response)


    If this answers your question please mark it accordingly. If this post is helpful, please vote as helpful by clicking the upward arrow mark next to my reply.

    Tuesday, October 14, 2014 8:43 AM
  • This article about activating tracing of the WCF Adapter helped me alot to analyse the traffic:

    "Use WCF message logging for fault monitoring and diagnosis of problems from the WCF adapters"

    http://msdn.microsoft.com/en-us/library/bb743607.aspx

    Regards

    Tuesday, October 14, 2014 10:01 AM
  • Hi

    I have read and configured the proxy settings in the WCF-Custom adapter under the credentials tab, however it still does not pick up any of the traffic to SAP.

    I have tried the following settings -

    http://localhost:8888/

    http://127.0.0.1:8888/

    http://<fully qualified computer name>:8888/

    This is all the guide in the link describes. Is there anything else?

    Regards

    Riaz

    Tuesday, October 14, 2014 10:02 AM
  • We are using the WCF-Custom adapter.

    For clarity, the WCF-Custom Adapter is just a wrapper for WCF.

    Are you using the sapBinding or one of the http based bindings?

    Tuesday, October 14, 2014 11:34 AM
    Moderator
  • Oh ok.

    Using the sapBinding

    Tuesday, October 14, 2014 12:17 PM
  • May be you can try out pass thru pipline at the response side. Or receivedIDOCformat change in the binding setup. (I have no exp in sap binding yet :) Just throwing wild guess. )

    Regards &lt;br/&gt; When you see answers and helpful posts,&lt;br/&gt; please click Vote As Helpful, Propose As Answer, and/or Mark As Answer

    Tuesday, October 14, 2014 12:36 PM
    Answerer
  • Hi,

    as someone has already requested - more information please!

    With the SAP Adapter it is important to grab all the information you can from the event log, the adapter publishes warnings that should really be errors.

    Does SAP ERP accept the message? using the SAP-side debugging tools, has that IDOC really been accepted?

    Fiddler??  Although it could become relevant in one of various ways that you can connect to SAP ERP and there is insufficient information in the base post to determine which approach you are using. I will hazard a guess and assume you are using SAP RFC, this is an entirely SAP private protocol. Fiddler is an HTTP tool. To trace this you could use WireShark with the CoreSecurity plugin. However there is no need as there is tracing already built-in to the SAP Adapter. This article describes how to enable tracing:

    http://social.technet.microsoft.com/wiki/contents/articles/13150.biztalk-server-wcf-based-sap-adapter-and-troubleshooting.aspx

    It has been update recently by Tomasso Groenendijk.

    I vaguely remember you can enable RFC tracing on the connection properties.

    Have fun.


    mark

    Wednesday, October 15, 2014 7:08 AM
  • If you say it was working until recently, I'm pretty sure that something has changed in SAP.

    What you can do to verify that no response is send back to BizTalk (why do you need a response anyway, is the GUID required on wards in your process? If not I would consider using a One-way Port instead of Solicit-Response):

    - Change the Receive Pipeline on your Solicit-Reponse SAP Port to PassThruReceive

    - Create a new File Send Port that subscribes to the following: BTS.SPName == [The name of your Solicit-Reponse SAP Port]

    If no messages are send to the File location, then no response is received by the Adapter.


    Morten la Cour 

    Wednesday, October 15, 2014 7:18 AM
  • I tried the pass thru pipeline and it gave me this error - 'Received unexpected message type '' does not match expected type'

    Thanks for the suggestion tho :)

    PS. I can view the response message which is perfectly formed xml as per the SAP IDOC schema. So i guess thats why the pass-thru doesnt work?
    • Edited by RiazP-MSDN Wednesday, October 15, 2014 8:03 AM
    Wednesday, October 15, 2014 8:00 AM
  • Hi Mark

    I have indeed confirmed that SAP has successfully received the IDOC, i can view in the SAP system using transaction WE02 for viewing IDOCs. I will have a look at that link, thanks!

    Regards

    Riaz

    Wednesday, October 15, 2014 8:02 AM
  • Hi Morten

    As explained above I tried the pass-thru pipeline for the response and can see the response message. We in fact dont use the GUID so perhaps I will implement a one-way port.

    What's strange is that this scenario works perfectly in our QAS BizTalk system.

    You are absolutely correct about the change in SAP. The IDOC versions were updated. However looking at the schema of the response messages they are the same, just a simple one field xml message with a GUID.

    I have seen a suggestion that deleting the port and re-creating it might work, I will try this too.

    Regards

    Riaz

    Wednesday, October 15, 2014 8:08 AM
  • But the error message you got about unexpected message type was from the Orchestration. Have you tried, together with the PassThruReceive Pipeline, to set up an additional File Send Port as I described earlier?

    Morten la Cour

    Wednesday, October 15, 2014 10:51 AM
  • Its a Static Solicit-Response port and the receive pipeline is an xml receive pipeline.

    This has always worked until recently. No messages are suspended and there is no additional info on the event logs.

    Is that mean there was no response at all? 

    You mentioned it worked all right before that. 

    If this was only for a single message, look into SAP, if SAP sends response or not.

    If it stopped working completely, look what was changed (environment settings, a new app deployed, etc.)


    Leonid Ganeline [BizTalk MVP]

    Wednesday, October 15, 2014 6:11 PM
    Moderator
  • Hi Riaz,

    Any luck with this problem?

    You said:

    >> You are absolutely correct about the change in SAP. The IDOC versions were updated. However looking at the schema of the response messages they are the same, just a simple one field xml message with a GUID.

    The change in versions is enough to mess things up. Just because the returned message looks functionally equivalent to the previous one - it must be in the exact same namespace as the previous one :-)

    For some related background: http://support.microsoft.com/kb/2388784

    Having said that it is not clear whether that is causing your error. It would help if you post the content off the response message. If the response message just contains a guid I'm thinking it is the RFC response which is very low level. Perhaps it is in the IDOC header format?

    mark


    mark

    Friday, October 17, 2014 7:18 AM
  • Hi Marc

    No luck so far.

    This is the content of the response message - 

    <SendResponse xmlns="http://Microsoft.LobServices.Sap/2007/03/Idoc/3/CREMAS05/ZCREMASX2/702/Send"><guid>549dd5f1-16f9-4302-94f3-cbef057cfcdc</guid></SendResponse>

    I'm going to try to delete the send port and re-create it, I have seen that this worked for someone else.

    Unfortunately as its not affecting the production interface I cannot make changes to the orchestration and deploy them to test different things.

    Regards

    Riaz

    Wednesday, October 22, 2014 8:53 AM
  • One rule of thumb I have been following (and suggested by my sap guys) while working with SAP is always take the latest version of Idoc. If I understood you correctly, your SAP guys updated the Idoc version in QA but you haven't replaced new version of Idoc with new version. If this is the case, then you will ultimately gonna have same issue in production when SAP people update the production system. Your WCF adapter is not complaining because it matches the deployed schema with the message you are attempting to send. Also SAP doesn't return error to BizTalk normally when you send old version of IDOC and they can't process it correctly. 

    Additionally, in my case I have been practicing Oneway port when I don't care about the GUID, and have no issue too.

    I am not clear why you are able to see response when you change pipeline to passthrough though. I have noticed when there is passthrough my wcf sap adapter is not able to deal with the response and complains "received unexpected message etc..". If you verified both Send and SendResponse schemas are not changed from visual studio then I would verify (just to be 100%) this from BizTalk admin console too (http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/mymessage#Send and http://Microsoft.LobServices.Sap/2007/03/Types/Idoc/mymessage#SendResponse).

    Another test practice that works for me is, I try to send just a valid IDOC instance using filedrop method and subscribing that message towards sap port and subscribe response message based on messagetype too. (Provided schema is already deployed). If this doesn't work I will surely consider replacing new schema version  and deploy it again and then test.


    Please mark it as Answer if this answers your question
    Thanks.
    Mo
    The contents I write here is my personal views, not the view of my employer and anyone else.

    Thursday, October 23, 2014 2:07 AM
  • Riaz,

    that looks good. It is a technical response from the lower level SAP ERP components confirming receipt of the message. I think it is strictly a tRFC message so the sender can check it off against your tRFC  database of sent messages. It comes from the local RFC component and the BizTalk adapter is wrapping it up

    Ask the SAP team if they enabled TRFC on that connection  - they almost certainly have.

    On the BizTalk connection, I'm guessing you have enabled tRFC but have not setup the database that goes with it. Not to worry if you haven't but it may be worth trying it out on a test system.

    I still don't have enough information to make a specific diagnosis but I would be looking to see if that schema is deployed. Look at all the deployed schema and carefully check the namespace on each. If the schema is there make a note of the Application that contains it. Here are some possible causes:

    1. the schema is not deployed (i.e. not present).  There is a fault in the SAP Adapter that can cause it to expect a different schema version (http://support.microsoft.com/kb/2388784). I believe that message is generated by the SAP Adapter from the tRFC response. Why would it not be deployed? because the one that is deployed is from the schema that you generated initially.

     2. The schema is there but your Application does not have access to it.

    3. The schema is there more than once! Ordinarily BizTalk gives a clear error for this however when the problem is detected in the SAP Adapter, it masks this error behind more generic "internal server error".

    I can't say for sure this is the cause but it will not take long to do the checks.


    mark


    • Edited by MarkTR Thursday, October 23, 2014 7:00 AM typo
    Thursday, October 23, 2014 6:58 AM
  • Hi Mohan

    I have replaced the new version of the IDOC in my BizTalk project and deployed the updated schema's to both QA and production when I began these changes.

    The issue only occurs in the production environment however.

    Regards

    Riaz

    Thursday, October 23, 2014 9:12 AM
  • Hi Mark

    I have requested SAP Basis to let me know about the TRFC, awaiting feedback.

    Further to your points - 

    1. Had a look at this link not sure it's relevant looking at the symptoms of my issue.

    2. How can I check this?

    3. Schema is there only once, scanned the applications resources and had a careful look at each schema using the schema view option as well.

    Regards

    Riaz

    Thursday, October 23, 2014 9:37 AM
  • Riaz,

    Re: 2 - how to check for access - Which Application is your project in  Which Application is the response schema in?

    They either have to be the same or the containing Application has to be referenced by the Application containing your project.

    Can you do another test (on dev) and then record all the events in the event log that are associated with the failure?


    mark

    Friday, October 24, 2014 5:39 AM
  • Hi Mark

    All resources are within the same application.

    Unfortunately i cant seem to re-produce the error on our QA box, it works perfectly there. Its only the production box that seems to be having this issue.

    Regards

    Riaz

    Friday, October 24, 2014 8:53 AM
  • Riaz,

    go back to whatever machine you saw the error on, then find an instance of the error in the Event Log and post whatever you find there. Grab. not just the error, but all the warnings and errors near the error. Often the "internal server error" is where the adapter gave up but the real cause is in a warning close-by.

    Did you deploy a change to production, found the problem, roll back the change ?  So now everything is fine?

    Regards 


    mark

    Saturday, October 25, 2014 7:50 AM
  • Hi Mark

    Unfortunately there is nothing in the event log. No errors, no warnings, nothing related to this error.

    I have not been able to solve the issue yet. I have deployed changes recently to some of the orchestrations in this project/application. However the error still pops up.

    Regards

    Riaz

    Monday, October 27, 2014 8:23 AM
  • Riaz.

    where did you find this error?

    > Error Description: An internal server error was encountered while attempting to transmit the message

    cheers

    mark


    mark

    Tuesday, October 28, 2014 11:41 AM
  • Hi Mark

    We have an SMTP send port which sends the exception message which is caught to an email group. It can also be viewed in the context of the SMTP error message.

    Regards

    Riaz

    Wednesday, October 29, 2014 12:33 PM
  • Hi All

    I've finally been able to test the theory of using another port. Sadly the issue still persists.

    I had read somewhere while researching this issue that someone deleted their port and re-created it and it solved the problem. It hasnt worked for me though.

    My only guess from this point is that there must a distinct difference between the SAP IDOC schema in our QAS and Production environments.

    My quest continues...

    Regards

    Riaz

    Thursday, October 30, 2014 9:19 AM
  • Riaz,

    and what were the error messages?

    Which SAP release is on the QAS system and on the PRD system?

    regards

    mark


    mark

    Monday, November 3, 2014 5:35 PM
  • Hi Mark

    Same scenario, no error messages except those mentioned above.

    QAS and PRD are on the same release - ECC 6.0.

    My next attempt will be to use a static one-way port, since we dont need the response message from SAP. I'm hoping this will work.

    Regards

    Riaz

    Wednesday, November 5, 2014 7:36 AM
  • Hi All

    Finally found the solution to this one.

    I was not aware that our production environment was split into two instances. After finding that out and looking in the event viewer of the second server I found this error - 

    'There was a failure executing the response(receive) pipeline: "Microsoft.BizTalk.DefaultPipelines.XMLReceive, Microsoft.BizTalk.DefaultPipelines, Version=3.0.1.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" Source: "XML disassembler" Send Port: "XXX_SEND" URI: "sap://XXXXX" Reason: The document specification <XXX.Schemas.IDOC_ZPREQ03_RESPONSE> from assembly <XXX.Schemas, Version=1.0.0.0, Culture=neutral, PublicKeyToken=ebeb85b54f9d7ba9> failed to load. Verify the schema for this document specification is deployed and is in the Global Assembly Cache'

    Needless to say I deployed the assemblies to this second server with a bit of effort due to concurrency violation errors but eventually got it done.

    All working fine now :)

    Thanks for the helpful tips.

    Regards

    Riaz

    • Marked as answer by RiazP-MSDN Thursday, December 18, 2014 6:26 AM
    Thursday, December 18, 2014 6:26 AM