locked
BizTalk Receive Port Exceptions RRS feed

  • Question

  • Hi

    Please suggest to  capture BizTalk Receive port exceptions like File path access deined, SQL Server connection failure??

    I know In orchestration , we can use scope shape to capture exception.

    Also, Send port , we can use delivery notifiation = transmitted to capture NACK ack and capture errors.

    but without Orchestration , how to capture Receive/Send port errors??

    By Default, biztalk stores exceptions in any BizTalk DB??

    I am able to see all exceptions are stored in event viewer. but not sure is it stored in DB as well ??

    Please Clarify?



    Thanks,

    Vinoth
    Tuesday, November 11, 2014 5:43 PM

Answers


  • You can consider enabling routing for failed message on both Receive port and in Send port. Enabling the "Enable routing for failed messages" promotes the ErrorReport properties when adapter (in your case) throws the exception. Then for these ErrorReport properties you can create subscription in Orchestration or send port to handle the error(s).

    Regarding Delivery notification failure, you always don’t need Orchestration to implement it. Even in messaging only scenario you can implement this functionality but with some custom code. In the send port, promote the following property to the context which would enable the NACK to be returned in the case of failure.

     pInMsg.Context.Promote("AckRequired", 
            "http://schemas.microsoft.com/BizTalk/2003/system-properties"
            true);

    Refer: Delivery Notifications outside Orchestrations - a pure Messaging approach

    You can consider the above options for your requirements.


    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, November 11, 2014 6:15 PM

  • Scanning event log or polling BizTalkMgmtDb and checking its status would be an overkill.

    In ideal world what you need is monitoring tools like BizTalk360/SCOM.

    Otherwise using SQL scripts/WMI/powershell should be the correct solution.

    Instead of scanning the Event Log and capturing when the Receive Locations or Send Ports go down, you can use the script from following article to send out an email when they change status:

    Notification when Receive Locations/Send Ports change

    Or refer the following article on using powershell:

    Tips and tricks for BizTalk monitoring with PowerShell


    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.

    Wednesday, November 12, 2014 1:10 PM

All replies


  • You can consider enabling routing for failed message on both Receive port and in Send port. Enabling the "Enable routing for failed messages" promotes the ErrorReport properties when adapter (in your case) throws the exception. Then for these ErrorReport properties you can create subscription in Orchestration or send port to handle the error(s).

    Regarding Delivery notification failure, you always don’t need Orchestration to implement it. Even in messaging only scenario you can implement this functionality but with some custom code. In the send port, promote the following property to the context which would enable the NACK to be returned in the case of failure.

     pInMsg.Context.Promote("AckRequired", 
            "http://schemas.microsoft.com/BizTalk/2003/system-properties"
            true);

    Refer: Delivery Notifications outside Orchestrations - a pure Messaging approach

    You can consider the above options for your requirements.


    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, November 11, 2014 6:15 PM
  • Its simple , create a Orchestration which be used for failed message routing .

    1)Create a message with  message type as  XmlDocument (which will be failed message inside messagebox)
     2) Put a filter condtion on the first receive shape as BTS.AckType property exists
      3) The logical receive port will use direct binding

    By doing so, all acknowledgments will be consumed by an instance of this orchestration, thus avoiding the routing failure.

    Thanks

    Abhishek

    Tuesday, November 11, 2014 7:06 PM

  • I am able to see all exceptions are stored in event viewer. but not sure is it stored in DB as well ??

    To clarify, yes, all of the cases you list would be logged in the Windows Event Log.

    To go a bit further, every error case, unless specifically handled and suppressed, would be logged in the Windows Event Log.  So, the Windows Event Log is the error database, there is no other place to look.

    No, BizTalk does not store errors in the database specifically, though the error text is associated with Suspended Instances when available.  No, you do not need to use delivery notification to capture Send Port errors.

    So, before doing anything else, does this not meet the requirement?

    • Proposed as answer by vittalaranga Wednesday, November 12, 2014 11:12 AM
    Tuesday, November 11, 2014 7:19 PM
    Moderator
  • Hi,

    As there is no execution of the orchestration (fails at receive) there can't be an exception. The BizTalk event viewer is the same as the build in windows event viewer. You can use System.Diagnostics.Eventlog class to obtain the information needed.

    Rachit

    Tuesday, November 11, 2014 7:28 PM
    Moderator
  • There is no way to capture file access exceptions or folder not found exceptions inside BizTalk. The simple answer to why would be that BizTalk never got the message. Same thing for other adapters such as SQL. If the WCF-SQL adapter can't connect to the database, the location will shut down and an event is written to the event viewer.

    Perhaps this is easier to explain if you consider that an adapter can be hosted outside BizTalk (such as in IIS).

    HTH

    Mikael


    If this answers your question, please use the "Answer" button to say so... Mikael - http://blogical.se/blogs/mikael

    Wednesday, November 12, 2014 4:18 AM
  • I do agree with Mikael ,You can not  have control over the process exception which occurs outside of BizTalk Environment . It wont be helpful to capture event (triggered in he event log ) as you wont be able to get Subscribing thread Id (which Orchestration Instance has triggered the exception ) and message , and without these information  it will be useless to capture event log errors

    So wise idea to concentrate on the exception which occurs inside BizTalk and we have already discussed the solution in above post .

    Thanks

    Abhishek

      
    Wednesday, November 12, 2014 5:29 AM
  • Hi ALL,

    Thanks for all your valuable Suggestions.

    Abhishek, I will try to implement your solution.

    But what currently I am facing is, there are some times file path(File adapter) not accessible due to network issue, it is trying re-attempt 3 times and disabled the received location. but there wont be any indication which the receive port disabled. 

    So, I think we have to create a windows service which is monitoring event viewer OR Polling the biztalk receive port tables in bizmgmtDB, whether any received location is disabled or not. based on that send a notification to support team..

    IS THIS RIGHT WAY OR ANY BETTER Solution??

    Thanks,

    Vinoth

    Wednesday, November 12, 2014 12:29 PM

  • Scanning event log or polling BizTalkMgmtDb and checking its status would be an overkill.

    In ideal world what you need is monitoring tools like BizTalk360/SCOM.

    Otherwise using SQL scripts/WMI/powershell should be the correct solution.

    Instead of scanning the Event Log and capturing when the Receive Locations or Send Ports go down, you can use the script from following article to send out an email when they change status:

    Notification when Receive Locations/Send Ports change

    Or refer the following article on using powershell:

    Tips and tricks for BizTalk monitoring with PowerShell


    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.

    Wednesday, November 12, 2014 1:10 PM
  • Hi ALL,

    Thanks for all your valuable Suggestions.

    Abhishek, I will try to implement your solution.

    But what currently I am facing is, there are some times file path(File adapter) not accessible due to network issue, it is trying re-attempt 3 times and disabled the received location. but there wont be any indication which the receive port disabled. 

    So, I think we have to create a windows service which is monitoring event viewer OR Polling the biztalk receive port tables in bizmgmtDB, whether any received location is disabled or not. based on that send a notification to support team..

    IS THIS RIGHT WAY OR ANY BETTER Solution??

    Thanks,

    Vinoth

    Yes ,that's pretty good idea , you can use  MSBTS_ReceiveLocation class to get the status of your receive location. Kent weare has a very good post here to get the status of your receive location

    wmi-scripting-for-biztalk-operations
    For checking the status of your Directory simply you need to implement system.io.directory mentioned in below link

    Check File path status

    Thanks

    Abhishek

     
    Wednesday, November 12, 2014 7:23 PM
  • IS THIS RIGHT WAY OR ANY BETTER Solution??

    Based on you additions to this thread, I will again advise that you don't need to do anything special, except monitor the Windows Event Log.

    Please don't over think this, there's no special or secret error log anywhere in BizTalk.

    Anytime a Receive Location disables, you will get an entry similar to:

    The receive location "Receive Location1" with URL "c:\nowhere\*.xml" is shutting down. Details:"The Messaging Engine failed while notifying an adapter of its configuration. ".

    You certainly can write your own Event Log monitor, it's not that difficult, but there are a number of low cost commercial tools that do the same.

    You can even have Windows take some action on the event, such as sending an e-mail from this sample: http://blogs.technet.com/b/jhoward/archive/2010/06/16/getting-event-log-contents-by-email-on-an-event-log-trigger.aspx

    Wednesday, November 12, 2014 7:42 PM
    Moderator
  • Hi Vinoth,

    The problem you are facing is a very generic problem and there are many known solutions to it so instead of wasting your time in writing some custom code have a look on below option.

    1) Use SCOM or BizTalk 360 for monitoring BizTalk Server(This will definitely be most effective as it will give other functionality and flexibility )

    http://www.microsoft.com/en-in/download/details.aspx?id=39617

    2) You can use powershell

    http://www.codit.eu/blog/2013/09/25/tips-and-tricks-for-biztalk-monitoring-with-powershell/

    3) Using WMI

    http://blogs.msdn.com/b/chrisromp/archive/2008/04/02/using-wmi-to-monitor-send-ports-and-receive-locations-in-biztalk-server.aspx

    4) And the link shared by John.

    http://blogs.technet.com/b/jhoward/archive/2010/06/16/getting-event-log-contents-by-email-on-an-event-log-trigger.aspx

    You can also go through below link which talks about different BizTalk Monitoring tools.

    http://social.technet.microsoft.com/wiki/contents/articles/5364.biztalk-monitoring-tools.aspx


    Thanks,
    Prashant
    ----------------------------------------
    Please mark this post accordingly if it answers your query or is helpful.

    Thursday, November 13, 2014 7:02 AM
  • I think the best solution here would be to incorporate a monitoring solution such as BizTalk360 if you can get it approved.  It will provide this type of coverage and so much more.

    http://kentweare.blogspot.com

    Friday, November 21, 2014 4:44 AM
    Answerer
  • I think the best solution here would be to incorporate a monitoring solution such as BizTalk360 if you can get it approved.  It will provide this type of coverage and so much more.

    http://kentweare.blogspot.com

    Wow Kent :) Happy to see you here

    Thanks

    Abhishek

    Friday, November 21, 2014 4:52 AM