locked
Error is going to the ESB portal and and also supended in admin console RRS feed

  • Question

  • Hi All,

    I have request and response port oin orchestration and also catching the general exception in orchestration if there is any fault,then I am sending to the ESB portal.

    Here the error is sending to ESB portal as expected and also it is suspended in admin console ,any suggestion ,it should not suspended in admin console.

    Thanks.

    Thursday, April 14, 2016 3:50 PM

Answers

  • That is actually expected and is the same for non-ESB scenarios. So, if you have a failure/error on a 2-way SendPort, both your SendPort and orchestration instance would get suspended.

    What you do with these instances is dependent on how the whole solution is planned to work - can you just terminate these/just resume these?

    Is it not acceptable to have both these go to the ESB Portal in your case? Once it's in the portal, what are you doing with it?

    Another option is not to enable Enable routing for failed messages at your SendPort, if you think only the published exception from the orchestration is good enough. In that case, you can use some scheduled WMI/powershell script to clean up these suspended instances.


    Thanks Arindam


    Thursday, April 14, 2016 5:51 PM
    Moderator

All replies

  • What is getting suspended in Admin Console? The orchestration or a Send/Receive Port Instance?

    If it's a Port, make sure Enable routing for failed messages is checked.


    Thanks Arindam

    Thursday, April 14, 2016 4:26 PM
    Moderator
  • Send port instance is suspended.

    But can I know why I need to enable the Enable routing for failed messages,because if there is any error it is catching in general exception from there I am triggering to the ESB portal.

    Thanks.

    Thursday, April 14, 2016 4:57 PM
  • You are catching the exception within your orchestration, and creating ESB exception which then makes it's way to the ESB portal.

    However, the suspended SendPort instance you are seeing is not something you can handle in this fashion. Any error at port level in BizTalk gets suspended by default, and there is nothing special in the ESB framework that changes this behavior. What ESB Toolkit does provide however is the ESB All Exceptions SendPort. It subscribes to all Failed messages across all Ports generated as a result of  enabling Enable routing for failed messages. So, your failed message at the SendPort will get subscribed by this ESB SendPort and make it's way to the ESB Portal.


    Thanks Arindam


    Thursday, April 14, 2016 5:29 PM
    Moderator
  • but If I checked enable failed message routing at send port level ,then two instances are sending to the ESB portal.One is from the Send port and other is from the orchestration.

    If port level message not suspended do I need to handle the fault at orchestration 2 way logical port?

    Thursday, April 14, 2016 5:44 PM
  • That is actually expected and is the same for non-ESB scenarios. So, if you have a failure/error on a 2-way SendPort, both your SendPort and orchestration instance would get suspended.

    What you do with these instances is dependent on how the whole solution is planned to work - can you just terminate these/just resume these?

    Is it not acceptable to have both these go to the ESB Portal in your case? Once it's in the portal, what are you doing with it?

    Another option is not to enable Enable routing for failed messages at your SendPort, if you think only the published exception from the orchestration is good enough. In that case, you can use some scheduled WMI/powershell script to clean up these suspended instances.


    Thanks Arindam


    Thursday, April 14, 2016 5:51 PM
    Moderator