none
Biztalk Questions. RRS feed

  • Question

  • Hello All,

    I have few questions as below,

    1) What is difference between enlisting, unenlisting and starting a send port  or an Orchestration ?

    2) How can we Process a pdf , audio and video files ?

    3) Why do we have Compensation option in Atomic transaction even it has default behavior of rollback ?

    4)What is use of Dehydration even though we are having persistence point that store state ?

    Can anybody answer these in details(by giving an examples) for me so that I will get clarity on this ?

    Thanks in advance.

     


    • Edited by _NiLeSh Tuesday, December 20, 2016 7:19 PM
    Tuesday, December 20, 2016 6:48 PM

Answers

  • Hi Nilesh,

    1) Refer: http://pnsoftwarestudies.blogspot.in/2013/11/EnlistingStartingStoppingAndUnenlistingSubscribers.html

    2) You can pass virtually any file (*.exe, *.dll, *.xls etc) through BizTalk Server’s messaging components. But In order for BizTalk Server to perform any processing on a message other than pass-through routing, the message must be in the XML file format.

    3) Compensation in BizTalk is supported for both long running and atomic Txs. While using compensation with long running Txs is the more common approach because there is no support for automatic rollback; however, in some cases, you might want to compensate an already committed atomic transaction; compensation can be used for such scenarios.

    Refer for other details: https://gautambiztalkblog.com/2015/05/25/biztalk-transactions/

    4) Orchestration Dehydration and Rehydration is possible because of the existence of persistence points. The orchestration engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point, as though nothing else had occurred.  Orchestration engine persist a running instance which is based on the design of orchestration. The event in which the Engine determines it wants to dehydrate, triggers the persistence operation called persistence points.



    Rachit Sikroria (Microsoft Azure MVP)


    Tuesday, December 20, 2016 7:32 PM
    Moderator
  • Hi Nilesh,

    1) unenlisting an subscriber means that the BizTalk engine is no longer aware that the entity will act as a subscriber, when you enlist the orch or the send port, BizTalk engine will have a knowledge that the entity is going to subscribe to a certain message based upon some evaluation criteria it basically means that when you enlist the orch or sendport, it will create the activation subscription and the BizTalk engine will route the necessary messages to it. Now once the subscription is created, the entity should process the message, for that to happen, you have to start it.

    2) Refer Richard Seroters blog,  Processing PDFs (or anything else!) in BizTalk Orchestrations\

    3) In case of atomic transactions, yes indeed rollback will happen if the steps in the atomic scope fails but there might be some business requirement that dictates to compensate the issue hence there is a provision to use the compensate block with the Atomic transactions

    4) Orchestration rehydration and dehydreation is derived from the persistence points, meaning when the orch dehyderates a persistence point is created, now in case of the dehyderation, BizTalk engine evaluates  when it is necessary to rehyderate the instance, suppose there is a crtical failure in the server then dehydration and rehydration will help BizTalk to process the messages in a proper and correct fashion.

    Regards


    Mandar Dharmadhikari

    Wednesday, December 21, 2016 3:34 AM
    Moderator
  • 4) Also, Dehydration is a technique for conserving server resources or, memory. Say, if you spin up 1000s of orchestrations and they all have to wait for a few hours/days before more progress can be made in the business process - in such scenarios the BizTalk engine decides to remove/dehydrate these orchestration instances from memory and free up RAM/memory. It is safe to do so since the orchestration would have hit a persistence point (meaning it's state is saved in the database).

    Once these orchestration instances receive any message that can trigger it's execution, they are rehydrated , or their state is loaded from the database into working memory, and the execution of the orchestration instance begins again.


    Thanks Arindam

    Thursday, December 22, 2016 12:28 PM
    Moderator

All replies

  • Hi Nilesh,

    1) Refer: http://pnsoftwarestudies.blogspot.in/2013/11/EnlistingStartingStoppingAndUnenlistingSubscribers.html

    2) You can pass virtually any file (*.exe, *.dll, *.xls etc) through BizTalk Server’s messaging components. But In order for BizTalk Server to perform any processing on a message other than pass-through routing, the message must be in the XML file format.

    3) Compensation in BizTalk is supported for both long running and atomic Txs. While using compensation with long running Txs is the more common approach because there is no support for automatic rollback; however, in some cases, you might want to compensate an already committed atomic transaction; compensation can be used for such scenarios.

    Refer for other details: https://gautambiztalkblog.com/2015/05/25/biztalk-transactions/

    4) Orchestration Dehydration and Rehydration is possible because of the existence of persistence points. The orchestration engine saves the state of a running orchestration instance at various points. If it needs to rehydrate the orchestration instance, start up from a controlled shutdown, or recover from an unexpected shutdown, it will run the orchestration instance from the last persistence point, as though nothing else had occurred.  Orchestration engine persist a running instance which is based on the design of orchestration. The event in which the Engine determines it wants to dehydrate, triggers the persistence operation called persistence points.



    Rachit Sikroria (Microsoft Azure MVP)


    Tuesday, December 20, 2016 7:32 PM
    Moderator
  • Hi Nilesh,

    1) unenlisting an subscriber means that the BizTalk engine is no longer aware that the entity will act as a subscriber, when you enlist the orch or the send port, BizTalk engine will have a knowledge that the entity is going to subscribe to a certain message based upon some evaluation criteria it basically means that when you enlist the orch or sendport, it will create the activation subscription and the BizTalk engine will route the necessary messages to it. Now once the subscription is created, the entity should process the message, for that to happen, you have to start it.

    2) Refer Richard Seroters blog,  Processing PDFs (or anything else!) in BizTalk Orchestrations\

    3) In case of atomic transactions, yes indeed rollback will happen if the steps in the atomic scope fails but there might be some business requirement that dictates to compensate the issue hence there is a provision to use the compensate block with the Atomic transactions

    4) Orchestration rehydration and dehydreation is derived from the persistence points, meaning when the orch dehyderates a persistence point is created, now in case of the dehyderation, BizTalk engine evaluates  when it is necessary to rehyderate the instance, suppose there is a crtical failure in the server then dehydration and rehydration will help BizTalk to process the messages in a proper and correct fashion.

    Regards


    Mandar Dharmadhikari

    Wednesday, December 21, 2016 3:34 AM
    Moderator
  • 4) Also, Dehydration is a technique for conserving server resources or, memory. Say, if you spin up 1000s of orchestrations and they all have to wait for a few hours/days before more progress can be made in the business process - in such scenarios the BizTalk engine decides to remove/dehydrate these orchestration instances from memory and free up RAM/memory. It is safe to do so since the orchestration would have hit a persistence point (meaning it's state is saved in the database).

    Once these orchestration instances receive any message that can trigger it's execution, they are rehydrated , or their state is loaded from the database into working memory, and the execution of the orchestration instance begins again.


    Thanks Arindam

    Thursday, December 22, 2016 12:28 PM
    Moderator