Clean up on abnormal termination of an orchestration? RRS feed

  • Question

  • I'm thinking about creating a file from an orchestration and deleting it when it ends. Nothing fancy but this file would need to be deleted when the orchestration terminates, no matter what. In a normal case, without error and such, I could be sure that the orchestration would delete the file before exiting but, is there a way to cleanup an orchestration if it gets suspended and terminated manually from the HAT or other abnormal mean?

    If I create an IDisposable class and use an instance in an orchestration, would it call it's dispose method (where I could put some clean up code to delete the file) on termination? Is there a way to be sure the file would always be deleted?

    Saturday, May 30, 2015 3:04 AM


All replies

  • First, I don't think creating a file in an Orchestration is a good idea to begin with. What are you trying to accomplish? Maybe there's a better way.

    Since Orchestration are just .Net Types, there's nothing preventing you from doing any of what you're asking.

    You can create a helper class for use inside the Orchestration that essentially 'owns' the file and implement the clean up there. Note, you need to implement IDisposable and a Finalizer. The GC doesn't actually call .Dispose() itself.  Here's an example: http://www.codeproject.com/Articles/413887/Understanding-and-Implementing-IDisposable-Interfa

    The one wrinkle here is Persistence. When an object is Persisted in BizTalk, to .Net, it's going out of scope and will be cleaned up. But you need your resource to stay 'managed' until the end. So, in addition to handling IDisposable and GC, you'll at least have to implement/override ISerializable to manage that process as well so you know when your instance is being Persisted vs. end of life.

    The one case you can't cover is Terminate.  When a service instance is Terminated in BT Admin, the records are just deleted from the database so there's no opportunity for you to clean up your resource (the file).

    Saturday, May 30, 2015 12:22 PM
  • Hi John and thanks for your answer. Yeah, the Terminate from the admin console is the edge case that I need to cover for the file idea to work... I thought that maybe Biztalk would call dispose on the orchestration variables before deleting it. What I'm trying to do is to keep track of how many instances of an orchestration type are running. I thought that simply creating a file when starting this type of orchestration and deleting it when it ends could work. I would simply have to count the number of files to know how many service instances are running. I really want to keep things simple. Using a database would have the same result as the file option since I could't decrement the number of running instances if someone Terminates one.

    We used to have a WMI request that would give the count of running instances, but I've been asked to remove that in order to ease up on the servers (we call WMI a lot and it seems that it is hard on the servers...). Do you see better alternative to achieve this?

    Saturday, May 30, 2015 2:39 PM
  • So...it would be next to impossible to convince me that keeping track of the number running Orchestration instances is a good thing to do.

    Exactly what problem are you trying to solve?

    Saturday, May 30, 2015 3:23 PM
  • Hi John and thanks for your time. I solved the above problem but I'm curious about how you would approach the requirements I'm facing. I would normally agree that keeping track of the number of running orchestrations is not great, but I didn't know how else I could meet these requirements.

    Here they are and unfortunately, they are non-negotiable (I work for a large organisation where everything is tightly controlled):

    • The only message queue available to me is the MessageBox or MQSeries (only 1 available queue in MQSeries);
    • I have 1 host to work with. The only way to transfer load on another host is to use a pipeline;
    • I need to guarantee at all time that I won't exceed a given number of allowed "processing" orchestrations. See it as a pool of orchestration that are shared across many "tasks";
    • The number of allowed processing orchestration varies according to the hour of the day and the day of the week;
    • I need to manage message priority. Some messages are urgent and can't wait for an available processing orchestration, those need to spawn a new one so they can be dealt with immediately. This makes FIFO Queue like MQSeries useless in this case;
    • The execution time of the processing orchestration may vary wildly, so, receiving new messages at fixed interval is out of the question. I really need to wait that one of the processing orchestration finishes before starting another one;
    • The maximum number of orchestration requirement isn't really coming from a Biztalk load, it is because of the load it generates on many shared external web services used during processing;
    • The only way to start a task is to receive a file containing many items. Each of these items will need to be processed by one of the orchestration of the pool. I can't modify the part of the system generating this file since it would impact external systems (big no no).
    • Probably forgetting some more.

    So, what kind of design would you favor with this kind of requirements?

    • Edited by chgag Tuesday, June 2, 2015 12:48 AM
    Tuesday, June 2, 2015 12:47 AM
  • Sounds like what you're looking for is a Resource Dispenser Pattern were you can create max-n number of Singletons to process the messages.

    Here's a Wiki Article that explains the process with Send Ports, but Orchestrations are essentially the same thing: http://social.technet.microsoft.com/wiki/contents/articles/23924.biztalk-resource-dispenser-send-port-edition.aspx

    If endpoint contention is really the problem, then this might address your need directly.

    For Orchestrations in the above sample, Priority messages would just get their own QueueId, 73427, instead of 2.  That way, regular message can queue up for 1, 2, 3 and 4 while 73427 spins up it's own instance immediately. The next Priority message gets 22453. The number doesn't matter, just that it's not 1, 2, 3 or 4.

    Alternatively, I just published this article describing a technique for running the same Orchestration different hosts allowing you to split Priority and non-Priority processing: http://social.technet.microsoft.com/wiki/contents/articles/31183.biztalk-running-orchestrations-in-multiple-hosts-on-the-same-computer.aspx

    If the message are really Priority, they should be treated as such.  The 1 Host requirement is almost counterproductive.

    • Marked as answer by Angie Xu Monday, June 8, 2015 6:05 AM
    Tuesday, June 2, 2015 1:30 AM