Skip to main content

By clicking Submit, you agree to the developerWorks terms of use.

The first time you sign into developerWorks, a profile is created for you. Select information in your developerWorks profile is displayed to the public, but you may edit the information at any time. Your first name, last name (unless you choose to hide them), and display name will accompany the content that you post.

All information submitted is secure.

  • Close [x]

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerworks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

By clicking Submit, you agree to the developerWorks terms of use.

All information submitted is secure.

  • Close [x]

Using Microsoft .NET in WebSphere Message Broker V8: Part 4: Using the .NETCompute node for exception handling

Ben Thompson (bthomps@uk.ibm.com), Consulting IT Specialist, IBM
Author photo
Ben Thompson is a Consulting IT Specialist working on the WebSphere Message Broker development team at the IBM Hursley Software Lab in the UK. He is currently working on the design and implementation of .NET support in Message Broker. In the past, he has worked for IBM Software Services for WebSphere designing and implementing WebSphere solutions for IBM customers worldwide. You can contact Ben at bthomps@uk.ibm.com.
(An IBM developerWorks Contributing Author)
Matthew Golby-Kirk (mgk@uk.ibm.com), Software Developer, IBM
Matthew Golby-Kirk photo
Matthew Golby-Kirk is a software developer working on the WebSphere Message Broker development team at the IBM Hursley Software Lab in the UK. He works on the design and implementation of the HTTP and Web services support, along with the ESQL language run time in WebSphere Message Broker. You can contact Matthew at mgk@uk.ibm.com.

Summary:  This series of four tutorials demonstrates the new support for Microsoft .NET in WebSphere Message Broker V8. Part 4 shows you how to use the .NETCompute node for exception handling, using a scenario that builds in complexity as additional exception conditions are deliberately produced and then handled. Readers should be familiar with either Microsoft .NET or WebSphere Message Broker, but need not be familiar with both.

View more content in this series

Date:  22 Feb 2012
Level:  Intermediate

Comments:  

Catching an exception when using the Propagate method in a .NETCompute node

  1. So far you have seen that the WebSphere Message Broker .NETCompute node API provides some methods to easily convert between the way that Message Broker reports exceptions (using the Exception List tree structure) and the more user-friendly formatted text messages for inclusion in output data. You can now extend the scenario by using a .NETCompute node to catch exceptions in the node during a rollback, which avoids having to catch exceptions using an explicit Catch branch in the flow. In WebSphere Message Broker Toolkit, return to the previously created message flow named MyFlow and insert another .NETCompute node between the MQInput node and the Throw node. Wire the Out terminal of the MQ Input node to the In terminal of the new .NETCompute node, and wire the Out terminal of the new .NETCompute node to the In terminal of the Throw node. Here is what the message flow should look like:

    Editted flow MyFlow
  2. Right-click .NETCompute1 (the new name for the .NETCompute node) and select Add Output Terminal:

    Add Output Terminal
  3. A pop-up window will ask you to name the new terminal. Specify Alternate:

    Name the new Output Terminal
  4. Add a second Trace node to the message flow from the Construction drawer of the palette and wire it between the Alternate terminal of the .NETCompute1 node (which you just created) and the In terminal of the existing MQ Output node:

    MyFlow with additional trace node added
  5. Set the Properties of the new Trace node as shown below:

    Node Trace1's properties
    Set the Destination property to File and the File path property to C:\student\DOTNET\lab_exceptions\trace1.txt. The listing below provides the Pattern property so that you can easily cut and paste the text:

    Listing 5. Text for the pattern property of the Trace node
    
    ===== ${CURRENT_TIMESTAMP} =====
    The Root of the message is:
    ${Root}
    The ExceptionList structure is:
    ${ExceptionList}
    

  6. Save the message flow: Type Ctrl-S or select File => Save. At this stage, the message flow should look like the image below. The red cross on the node .NETCompute1 indicates that a .NET assembly has not yet been assigned to the node.

    Saved message flow MyFlow
  7. Switch windows to Microsoft Visual Studio, which should still have the project named ExceptionsDotNetProject open. Expand the Solution Explorer view, right-click on the ExceptionsDotNetProject level in the hierarchy, and from the menu select Add => Class:

    Solution Explorer Add Class menu
  8. In the dialog, select the Message Broker template named Class to Create a Message Broker message, keep the suggested name of CreateNode1.cs, and click OK:

    Add Class dialog
  9. In the generated class CreateNode1.cs, at the beginning of the Evaluate method, and after the declaration of the NBOutputTerminal object that represents the node's Out terminal, add a new declaration for the Alternate output terminal that you added to the message flow node. The C# code is shown below with the new line in bold:

    Listing 6. Code extract for the declaration of the Alternate output terminal
    
    public override void Evaluate(NBMessageAssembly inputAssembly)
    {
        NBOutputTerminal outTerminal = OutputTerminal("Out");
        NBOutputTerminal altTerminal = OutputTerminal("Alternate");
        NBMessage inputMessage = inputAssembly.Message;
        .....
    

    This NBOutputTerminal object will be used below when you send a message out of the .NETCompute1 node in the circumstances where the node has caught a downstream exception.
  10. Edit the UserCode region of the class CreateNode1.cs using the code in the listing below. This snippet of C# simply copies the body of the input message to the output message assembly:

    Listing 7. Code extract for the UserCode region
    
    #region UserCode
    // Add user code in this region to create a new output message 
    // Copy the input message to the output
    outputRoot.AddLastChild(inputRoot.LastChild);
    #endregion UserCode
    

  11. Beneath the UserCode region, you will find a line of code responsible for sending the output message assembly out of the .NETCompute node to the Output terminal. By default, this code will look like this:

    Listing 8. Propagation code before editing
    // Change the following if not propagating message to the 'Out' terminal
    outTerminal.Propagate(outAssembly);
    

    Surround this code with a Catch block, so that if an exception occurs on the message flow thread that executes the Propagate (including subsequent message flow logic downstream of this point in the message flow), then it will be caught in .NETCompute1, rather than being rewound further back to the MQ Input node. Use the replacement code below (remove the two lines above and put the code below in its place), and you will see that if an exception is caught, the C# code will generate a description from the exception (the code uses the FormattedMessage method if the exception is a Broker exception type). An output message is built containing this description and then propagated to the Alternate terminal of the node:

    Listing 9. Propagation code after editing
    try
    {
        outTerminal.Propagate(outAssembly);
    }
    catch (NBBrokerException downstreamBrokerException)
    {
        outputRoot.LastChild.Delete();
        // The NBBrokerException which is caught here could contain CLR exceptions
        // e.g. If a .NETCompute node were responsible for the downstream throw.
        // So, to bullet proof this code, we use GetBaseException and then: 
        //   If we have an NBRecoverableException, use method FormattedMessage 
        //   If we have a non-Broker exception, use method ToString
        Exception exc = downstreamBrokerException.InnerException.GetBaseException();
        NBRecoverableException nbrecov = exc as NBRecoverableException;
        String pleasantExceptionMessage;
        if (nbrecov != null )
        { 
            pleasantExceptionMessage = nbrecov.FormattedMessage(false);
        }
        else
        {
            pleasantExceptionMessage = exc.ToString();
        }
        // Create an output message which contains the exception information
        NBElement outputXMLNSC =
            outputRoot.CreateLastChildUsingNewParser(NBParsers.XMLNSC.ParserName);
        NBElement field = 
            outputXMLNSC.CreateFirstChild("Message").CreateFirstChild("Field");
        field.CreateFirstChild(NBParsers.XMLNSC.AsIsElementContent, 
            "", pleasantExceptionMessage);
        // Propagate the message to the Alternate output terminal
        altTerminal.Propagate(outAssembly);
    }
    

    The block that catches downstream problems with the Propagate method deliberately catches NBBrokerException and not NBException, which is at a higher level in the Message Broker exception hierarchy and can include fatal exceptions that should not be caught within a flow developer's code. The Broker exception hierarchy is shown below. NBBrokerException is a special wrapper exception designed to catch exceptions from downstream nodes that will successfully catch all other types of downstream exceptions on which a flow developer might want to take action.

    Message Broker exception inheritance hierarchy
  12. With the Visual Studio development work complete, build an assembly file containing the two classes -- the one you created earlier in the tutorial and the one you just wrote -- which will be referenced from the .NETCompute nodes in the message flow. From Solution Explorer, right-click on the Solution and select Build Solution:

    Build solution containing two classes
    At this stage, if you happen to have the Windows Event Log open, you will notice a hot swap deploy error for the first .NETCompute node in the flow. This error occurs because the assembly now contains two classes, and the node has not yet been configured to nominate which of the two classes it should use. You will put this right in the next instruction, but don't be alarmed if you see the hot swap deploy error in the Event Log.
  13. Return to Message Broker Toolkit and the message flow MyFlow. Now that the assembly contains two classes (one for each .NETCompute node), you must tell each .NETCompute node in the flow which class to use:

    Edit the Basic properties of the node .NETCompute1:

    Assembly name = C:\student\DOTNET\lab_exceptions\visual studio 2010\Projects\ExceptionsDotNetProject\ ExceptionsDotNetProject\bin\Debug\ExceptionsDotNetProject.dll
    Class name = ExceptionsDotNetProject.CreateNode1

    Basic properties of node .NETCompute1

    Edit the Basic properties of the node .NETCompute:

    Assembly name = C:\student\DOTNET\lab_exceptions\visual studio 2010\Projects\ExceptionsDotNetProject\ ExceptionsDotNetProject\bin\Debug\ExceptionsDotNetProject.dll
    Class name = ExceptionsDotNetProject.CreateNode

    Basic properties of node .NETCompute
  14. Save the message flow, return to the open test client, right-click the Invoke Message Flow level in the hierarchy on the panel on th left, and select Re-run. The flow should be redeployed and the same Hello World! message will be sent to the input queue again:

    Invoking the Test client
  15. The output message from the test should appear on the output queue DOTNET.EXCEPTIONS.CATCH, and should have the same message content as the last test, except that this time the route followed through the flow will be slightly different. The image below shows that the rollback does not go all the way back to the MQ Input node. The input message follows the path of the blue arrow (A), and on reaching the Throw node, a rollback (red arrow B) occurs which is then caught by the node .NETCompute1. The output message is then propagated down the path of the green arrow (C):

    Flow paths
  16. To check that the message was directed along the paths shown above and through the new trace node Trace1, make sure that there is now a second trace file, Trace1.txt, in the directory C:\student\DOTNET\lab_exceptions:

    Trace output file
  17. Open the trace file Trace1.txt and you should find it contains a trace of the XML exception message generated by the .NETCompute1 node. Check the body of the message, and extract of which is shown below:

    Listing 10. Extract from trace file Trace1.txt
    
    (0x01000000:Folder):XMLNSC = ( ['xmlnsc' : 0xd4c37a0]
      (0x01000000:Folder):Message = (
        (0x01000000:Folder):Field = (
          (0x03000600:AsisElementContent): = '( MB8BROKER.default ) Exception 
          thrown by throw node 'MyFlow.Throw'; text is 'This is a deliberate 
          exception!'. The throw node 'MyFlow.Throw' has received a message 
          and thus has thrown an exception as this is its normal behavior. 
          The message text associated with this exception is 'This is a 
          deliberate exception!'. Since this is application generated (by 
          message flow behavior), the user action is determined by the 
          message flow and the type of exception generated. ' (CHARACTER)
        )
      )
    )
    

5 of 10 | Previous | Next

Comments



Help: Update or add to My dW interests

What's this?

This little timesaver lets you update your My developerWorks profile with just one click! The general subject of this content (AIX and UNIX, Information Management, Lotus, Rational, Tivoli, WebSphere, Java, Linux, Open source, SOA and Web services, Web development, or XML) will be added to the interests section of your profile, if it's not there already. You only need to be logged in to My developerWorks.

And what's the point of adding your interests to your profile? That's how you find other users with the same interests as yours, and see what they're reading and contributing to the community. Your interests also help us recommend relevant developerWorks content to you.

View your My developerWorks profile

Return from help

Help: Remove from My dW interests

What's this?

Removing this interest does not alter your profile, but rather removes this piece of content from a list of all content for which you've indicated interest. In a future enhancement to My developerWorks, you'll be able to see a record of that content.

View your My developerWorks profile

Return from help

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere
ArticleID=795296
TutorialTitle=Using Microsoft .NET in WebSphere Message Broker V8: Part 4: Using the .NETCompute node for exception handling
publish-date=02222012
author1-email=bthomps@uk.ibm.com
author1-email-cc=
author2-email=mgk@uk.ibm.com
author2-email-cc=

Tags

Help
Use the search field to find all types of content in My developerWorks with that tag.

Use the slider bar to see more or fewer tags.

Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere).

My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).

Use the search field to find all types of content in My developerWorks with that tag. Popular tags shows the top tags for this particular content zone (for example, Java technology, Linux, WebSphere). My tags shows your tags for this particular content zone (for example, Java technology, Linux, WebSphere).