so that you do not continually throw a RetryTransactionException and create an infinite retry loop. in C#

Creating PDF 417 in C# so that you do not continually throw a RetryTransactionException and create an infinite retry loop.

Atomic Scope shapes (as well as other Scope shapes) support the notion of compensation to facilitate undoing a logical piece of work regardless of the successful commit. Suppose that the atomic scope executes and commits successfully, but there is a business-error problem with the message data. The atomic scope, from a technical aspect, executed and committed correctly. However, due to the business validation failing, the transaction must be undone. Compensations allow definition of a process that details how the previously committed atomic transaction is to be rolled back. The structure of a compensation handler is similar to that of an exception handler but functionally different. BizTalk will use the default compensation handler if no custom compensation handler is defined. The default BizTalk compensation handler calls the compensation blocks of any nested transactions, in reverse order of completion. Compensation handlers must be called explicitly, unlike error handlers, through the use of the Compensation shape. A common use for a compensation handler is to create a message that indicates business data needs to be backed out of a specific system or process.

An Atomic Scope shape behaves like an MSDTC transaction but is not an explicit DTC transaction by default. To clarify, if you send a message to SQL Server via the SQL adapter, the actions performed in the SQL call will not roll back, and a compensation handler is required to back out any committed changes. The reason a compensation handler is required is due to the SQL adapter not enrolling in an explicit DTC transaction.

Atomic scopes do support the use of a DTC transaction as long as the objects referenced in the scope are serviced components (COM+ objects) derived from the System.EnterpriseServices.ServicedComponents class. Additionally, the isolation levels must agree and be compatible between transaction components and what is specified in the atomic scope. The atomic scope does not require a configuration value to be set on the shape itself, as it will automatically enroll in an MSDTC transaction if possible. Listing 5 5 serves as an outline for what to include in your assembly for creating a serviced component. Your assembly must reference System.EnterpriseServices and System.Runtime.InteropServices (for the Guid attribute reference). Verify that your component is registered in the Global Assembly Cache (GAC) (for example, using gacutil) and that you also register the component in COM+ (for example, using regsvcs). Listing 5 5. Serviced Component using System; using System.EnterpriseServices; using System.Runtime.InteropServices; namespace MSDTCTestLibrary { /// <summary> /// Summary description for Class1. /// </summary> /// [Guid("9943FB26-F4F5 4e80-B746-160AB9A6359E")] [Transaction(TransactionOption.Required)] public class ClassMSDTCTest : ServicedComponent { public ClassMSDTCTest(){} public String Test() { try { // Commit the transaction ContextUtil.SetComplete(); return "Test"; } catch (Exception ex) { // Abort the transaction ContextUtil.SetAbort(); return ex.ToString(); } } } }

You have separate tasks to accomplish in an orchestration that must all succeed or fail together. These tasks may take a long time to complete.

Long-running transactions can help ensure a single consistent outcome across multiple BizTalk tasks. As an example, suppose you have a web site where customers can make purchases using credit. Creating a new customer involves two steps. First, the customer needs a login to access your web site. Second, the customer also needs credit established to make purchases. Sometimes, your web site cannot create a login because the customer has chosen a login already assigned to another customer. Other times, BizTalk cannot establish credit for the customer. If one of these tasks succeeds and the other fails, the user may experience undesirable behavior on your web site. By defining actions to reverse each of the two tasks required in this example, BizTalk can automatically reverse the effects of one task in the event that the other fails. If BizTalk creates a login but cannot establish credit, it will detect the failure and invoke the compensation logic to disable the login. If credit is established but BizTalk cannot create the login, it will invoke the compensation logic to suspend credit. The following steps demonstrate how to set up a long-running transaction for this example. 1. 2. 3. 4. 5. 6. 7. Create a new BizTalk project, and add an orchestration. Right-click the orchestration design surface, and select Properties Window. Set the Transaction Type property to Long Running. Place a Receive shape on the design surface with the Activate property set to True. Configure BizTalk to receive a NewCustomerMsg message. Place a Parallel Actions shape under the Receive shape. Place a Scope shape under the left branch of the Parallel Actions shape. Select the icon in the upper-right corner of the Create Login shape, and select Long Running from the menu, as shown in Figure 5 51.