Announcement Announcement Module
Collapse
No announcement yet.
File and Exception handling Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • File and Exception handling

    Hi,

    I've successfully (and very easily I might add) set up an application to poll a directory for new files, process those file by calling a service and move them to a 'Processed' directory. I'm now attempting to deal with errors. What I need to do if the service throws an exception is i) move the file to an 'Problem' directory and ii) generate a log file in the same 'Problem' directory recording the exception.

    The reference manual on exceptions states that after an exception is throw the message payload becomes the actual exception. So, my first, and most important, question is how do I configure SI to move a problem file to a specific output directory? My second requirement of logging the exception can probably be dealt with using a logging framework but if there's something built in I could use that would be great.

    thanks,
    Jonny

  • #2
    I shouldn't have been so hasty at posting the question, I figured it out by looking at the ErrorUnwrapper class in the examples.

    Thanks.

    Comment


    • #3
      Ah, looks like a job well done by yours truly . I was thinking when I read your first post in my reader that maybe the <file:file-mover .../> is missing from the framework, if you agree you can create an issue for that. Going over the file support again, especially the namespace, might be a good idea for 2.0 anyway.

      Comment


      • #4
        Actually, after having implemented what I needed, I'm not sure a move file is needed as its own entity.

        With the current system the message paths I ended up with are very clear with very well defined responsibilities (which from experience is a good goal to aim for with regards to maintainability). The message flow is: transform to byte[] and delete, process, write byte[] back out. What changes is just the channel used to process the output, normal vs error. A simple message router on the error channel that sends the error message to two channels easily allows a log file to be generated in a third location.

        Once I realized I could obtain the original message from the error message the solution was clear. Maybe just an extension of the documentation regarding error handling or some specific examples? From previous experience with ESBs the handling of error situations can be the tricky part that you need to do before putting a system into production but that is glossed over in the examples/documentation. It's been a while since I used another ESB but the error handling in SI is more straightforward that I remember from others.

        thanks
        Jonny

        Comment


        • #5
          Originally posted by jwray View Post
          A simple message router on the error channel that sends the error message to two channels easily allows a log file to be generated in a third location.
          I am not sure what your exact use case is in terms of the two channels you mention above, but the default error channel is a publish-subscribe channel. So, you can have multiple subscribers with an input-channel value of "errorChannel".

          Comment


          • #6
            Use case is that two things happen to the error message: i) the original file is written to an error directory and ii) an error log is created from the service exception.

            For some reason I never think of publish-subscribe channels. And yes, it does sound like it'll do exactly what I'm after.

            Thanks
            Jonny

            Originally posted by Mark Fisher View Post
            I am not sure what your exact use case is in terms of the two channels you mention above, but the default error channel is a publish-subscribe channel. So, you can have multiple subscribers with an input-channel value of "errorChannel".

            Comment

            Working...
            X