Thursday, March 19, 2009

The current transaction cannot be committed when using service broker

The current transaction cannot be committed when using service broker
=================================================================
when we use service broker queue to comunicate biztalk and sql sever we might get error meaasgae in some cases.To avoid this use xact_state(). Is a scalar function that reports the user transaction state of a current running request. XACT_STATE indicates whether the request has an active user transaction, and whether the transaction is capable of being committed.
The current request has an active user transaction. The request can perform any actions, including writing data and committing the transaction.

1 - The current request has an active user transaction. The request can perform any actions, including writing data and committing the transaction.
0 - There is no active user transaction for the current request.
-1 - The current request has an active user transaction, but an error has occurred that has caused the transaction to be classified as an uncommittable transaction. The request cannot commit the transaction or roll back to a savepoint; it can only request a full rollback of the transaction.
SET XACT_ABORT ON;
BEGIN TRY
BEGIN TRANSACTION;
-- A FOREIGN KEY constraint exists on this table. This
-- statement will generate a constraint violation error.
DELETE FROM Production.Product WHERE ProductID = 980;
-- If the delete operation succeeds, commit the transaction. The CATCH
-- block will not execute.
COMMIT TRANSACTION;
END TRY
BEGIN CATCH
-- Test XACT_STATE for 0, 1, or -1.
-- If 1, the transaction is committable.
-- If -1, the transaction is uncommittable and should
-- be rolled back.
-- XACT_STATE = 0 means there is no transaction and
-- a commit or rollback operation would generate an error.
-- Test whether the transaction is uncommittable.
IF (XACT_STATE()) = -1
BEGIN PRINT 'The transaction is in an uncommittable state.' + ' Rolling back transaction.'
ROLLBACK TRANSACTION;
END;
-- Test whether the transaction is active and valid.
IF (XACT_STATE()) = 1
BEGIN PRINT 'The transaction is committable.' + ' Committing transaction.'
COMMIT TRANSACTION;
END;
END CATCH;
GO

Sunday, March 15, 2009

AJAX is an acronym for Asynchronous JavaScript and XML. JavaScript is a scripting language that is supported by all of the major browsers. With AJAX, an application running in the browser can use JavaScript to send an XML message to the server, the server works on the request and sends an XML response back to the browser client, and the browser uses JavaScrip to process the response.
The AJAX Page Life Cycle
pageLoad Called after page is loaded from the Web server
pageUnload Called when page redirects, posts back, or makes an asynchronous call to the server
The UpdatePanel Control
The UpdatePanel enables partial-page updates, which is one of the most compelling reasons to use AJAX. It is responsible for eliminating the page flicker and scrolling back to the top of the page after postback—experience that people have become accustomed to but are still uncomfortable with all the same.
The UpdateProgress Control
Sometimes a partial-page postback takes longer than normal. Instead of making the user sit there wondering what is happening, it would be better to give the user some type of status. The UpdateProgress control helps in this area by letting the user know that progress is being made.



Saturday, March 14, 2009

Silverlight

Silverlight is a combination of different technologies, working harmoniously together to make it easier to build RIAs. Essentially, you can take parts of what you know about Extensible Application Markup Language (XAML), Windows Presentation Foundation (WPF), ASP.NET,
JavaScript, and AJAX combined with a lightweight runtime to create incredible browser experiences that were once only the domain of Flash.

Friday, February 20, 2009

Workflow architecture

The workflow functionality in Windows SharePoint Services 3.0 is built on the Windows Workflow Foundation (WF), a Microsoft Windows platform component that provides a programming infrastructure and tools for development and execution of workflow-based applications. WF simplifies the process of asynchronous programming to create stateful, long-running, and persistent workflow applications. The WF run-time engine manages workflow execution and allows workflows to remain active for long periods of time and to survive restarting the computer. Run-time services offer functionality such as transactions and persistence to manage errors gracefully and correctly.

The WF run-time engine provides the services that every workflow application needs, such as sequencing, state management, tracking capabilities, and transaction support. The WF run-time engine serves as a state machine responsible for loading and unloading workflows, as well as managing the current state of any workflows that are running. WF allows any application process or service container to run workflows by hosting WF — that is, loading WF within its process.

Windows SharePoint Services hosts the WF run-time engine. In place of the pluggable services that are included with WF, Windows SharePoint Services provides custom implementations of the following services for the engine: transaction, persistence, notifications, roles, tracking, and messaging. Developers can then create workflow solutions that run within Windows SharePoint Services.

Tuesday, February 17, 2009

Types of Workflows

Types of Workflows

Windows Workflow Foundation supports two fundamental workflow styles:
Sequential workflows Represents a workflow as a procession of steps that execute in order until the last activity completes. However, sequential workflows are not purely sequential in their execution. Because they can receive external events and include parallel logic flows, the exact order of activity execution can vary.
State machine workflows Represents a set of states, transitions, and actions. One state is denoted as the start state, and then, based on an event, a transition can be made to another state. The state machine can have a final state that determines the end of the workflow.
You can create workflows of either type for Windows SharePoint Services and SharePoint Server.
Sequential Workflows
Sequential workflows can best be represented graphically as a flowchart of actions, with a beginning, an end, and a sequential flow direction from start to finish. Sequential workflows can incorporate flow structures such as repetition, looping, and parallel branches, but ultimately progress from the initial action to the final action.
For example, suppose you were to chart the simple workflow that routes a document in Windows SharePoint Services for approval. When the workflow starts, the system notifies the specified reviewer, by e-mail message, that he or she has a document to review. The reviewer then reviews the document and notifies the system that the task is completed and whether the reviewer approves or rejects the document. Based on the reviewer response, the workflow executes one of two parallel branches. If the reviewer approved the document, the system moves the approved document to a specific SharePoint document library and then sends an e-mail message to the entire team notifying them of the approved document. If the reviewer rejects the document, the system notifies the document author.


State machine workflows
Unlike sequential workflows, state machine workflows do not have a prescribed execution flow, and need not have an end. Instead, state machine workflows define any number of states which an item may inhabit, and the events that transition the item from one state to another.
For Example, The workflow is initiated when a document is created, and ends when the document state is set as completed. In between, however, the document does not travel in a predetermined path, but instead transitions from state to state as events occur.
The state machine workflow is composed of state activities. Each state activity represents a state for the item. Each state activity can contain optional state initialization, state finalization, and one or more event handlers. Each event handler activity can handle one event. In response to the event handled, some processing can be done, and a transition can be made to another state.