ServiceBroker•Chapter12 527 EXERCISE 12.2 Cr e a t i n g Me S S a g e ty p e S Create four message types within the AdventureWorks database. Use the validation NONE for two of them and WELL_FORMED_XML for the other two. Create the Message Types based on the data shown in Table 12.1. Contracts Within the SQL SERVICE BROKER a contract defines what message types can be used on a single conversation and which side of the conversation can use which message types. Every conversation uses a single contract for the duration of the conversation. If you wish to use a different contract during an existing conversation you have to close the conversation and create a new one. When defining the contract you specify which end of the conversation can use which message type. The initiator of the contract is the sender of the message, and the target of the contract is the receiver of the message. Like the Message Type, the name of the contract can be up to 128 characters and is created using the AUTHORIZATION statement to assign ownership of the object to a specific user or role within the database. When naming your contract do not name the contract with the keyword ANY. If you create a contract using the keyword ANY as the name you will not be able to successfully assign priorities to the conversations using the CREATE BROKER PRIORITY command. The use of this command is outside the scope of this text; however, you can read more on this command in Books OnLine under the index setting “CREATE BROKER PRIORITY statement.” SQL SERVICE BROKER Contracts are created using the CREATE CONTRACT command. The CREATE CONTRACT command is very straightforward with few options when creating the contract. Message Type Name Message Type Validation MT _None NONE MT _XML WELL_FORMED_XML Table 12.1 Message Types and Their Validations 528 Chapter12•ServiceBroker CREATE CONTRACT [YourApplication/Contract1] AUTHORIZATION dbo ( [YourApplication/YourMessageType] SENT BY INITIATOR, [AnotherApplication/AnotherMessageType] SENT BY TARGET ); When looking at this example code, you can begin to see why the naming conventions shown here can make it quite a bit easier to see which SQL SERVICE BROKER objects go with which Application. Ex a m Wa r n i n g Pay special attention to the SENT BY options in the exam. The various options can get confusing during the exam. Also pay attention to the wording of the questions. If you wish to create a contract that uses the same Message Type for both the initiator and the target either you can specify the Message Type twice as done above, or you can specify that the Message Type be sent by ANY as shown here. CREATE CONTRACT [YourApplication/Contract1] AUTHORIZATION dbo ( [YourApplication/YourMessageType] SENT BY ANY, ); Either syntax is perfectly acceptable, and neither is incorrect. There is no ALTER CONTRACT command in SQL Server 2005 or SQL Server 2008; perhaps this command will make it into a future version. This prevents you from adding or removing a Message Type from the contract after the contract has been created. The only way to add or remove a Message Type from a contract is to create a new contract, modify all services that reference that contract to use the new contract, and then remove the original contract from the database using the DROP CONTRACT command. There is no easy way to see after creating the contracts which Message Types are contained within the contracts. You can manually right-click on each contract in the object explorer and script each object out. In a large SQL SERVICE BROKER environment this could take hours or days to the SQL Server database. Because of this, having a good knowledge of the SQL SERVICE BROKER Catalog ServiceBroker•Chapter12 529 Views is extremely important. You will find the meta data about the Message Types in the sys.service_message_types catalog view, and the meta data about the contracts in the sys.service_contracts catalog view. The linking view between these two catalog views is the sys.service_contract_message_usages catalog view. This view contains the id of the contract and the Message Type, as well as bit flags for which end of the conversation can use the message type. In SQL Server 2008 a properties screen was introduced, which will allow you to view the contract and see what Message Types are bound to the contract. However, there is no way to view which contracts are bound to which Message Types. eXerCiSe 12.3 Cr e a t i n g Co n t r a C t S Create two contracts. Each contract should be bound to both message types. Use the chart shown in Table 12.2 when creating your contracts. Queues The SQL SERVICE BROKER queue is where the messages are sent to and received from. You can think of them as kind of like tables, except that you cannot change the structure of them. Just like a table you can select data from the queue, and doing so will not affect the messages within the queue. However, because this is a SQL SERVICE BROKER queue and not a table you cannot INSERT, UPDATE, or DELETE any of the data within the queues. Because queues are physical objects created within the database, you can specify a database schema that contains the object, however, it is most common to leave the queue in the dbo schema. As the queue is a physical object that stores the messages that are sent to it, you will need to specify the SQL Server File Group that will store the data from the messages in it. Contract Name Message Types CT_Sender MT_ None MT_ XML CT_Receiver MT_ None MT_ XML Table 12.2 Contracts and Message Types 530 Chapter12•ServiceBroker When creating the SQL SERVICE BROKER queues you have several options from which you can select. You can enable or disable the queue from receiving messages via the STATUS option. You can tell the SQL SERVICE BROKER to keep messages after they have been received or to delete them after they have been received via the RETENTION flag. You also have the option of having a stored procedure be run by the SQL SERVICE BROKER by using the ACTIVATION settings. By default the STATUS setting will be enabled, and the RETENTION setting will be disabled. The ACTIVATION setting will be enabled by default, however, without the procedure name set no action will be taken until you specify the name of the stored procedure to execute. This procedure, if specified, must exist. Therefore, it is recommended that you create the queue, then the procedure that will read from the queue, then use the ALTER QUEUE command to set the activation procedure. With the exception of setting the file group all options that are available in the CREATE QUEUE command are available in the ALTER QUEUE command. Activated stored procedures are probably one of the most important parts of the SQL SERVICE BROKER system. They allow the SQL Server to automatically start a stored procedure when a message arrives so that messages can be processed as quickly as possible. You can even control how many copies of the stored procedure are running—from a single thread up to 32,767 threads. You will want to be very careful with how high you set this setting since setting it too high could cause your SQL Server CPU to increase as you add thousands of threads to the system. Configuring & Implementing… Message Queues in the Real World SQL SERVICE BROKER is used by many companies in many different ways. Pretty much anything that doesn’t need to give data back to the user can be set up to go through the SQL SERVICE BROKER. This gives the user a faster experience since the user interface does not have to wait for the process to be completed. Some of the various things that can be done with the SQL SERVICE BROKER include data logging, Windows service to Windows service messages, and physical file manipulation. Continued ServiceBroker•Chapter12 531 When you increase the number of threads that the Queue will run in parallel and there are already messages in queue, the new threads will normally start within a few seconds. When you reduce the number of threads, no threads are halted at that time. The threads must stop on their own by running out of messages to process. No new threads will be started, but there will be more threads running than are configured until those threads begin to end. The same effect occurs if you stop the activation. No new threads will be started but the running threads will continue to process until they run out of messages to process. If you change the procedure name of the activated procedure then the new procedure name will not be used until there is room for a new thread to be started in the number of threads running. If you have the queue configured for five threads and there are five threads running when you change the procedure name, the new procedure will not be used until after one thread has stopped. At this time the new procedure name will be used when the new thread is started. If you need to stop all the activated procedures from processing any additional messages then you will want to disable the queue, which will prevent the activated procedures from receiving any new messages out of the queue, causing the procedures to exit after they have finished processing the current message. Using an example let’s look at how the queue is going to handle the activated stored procedure. First, we will make a few assumptions about the dbo.YourProcedure procedure and the queue. 1. The procedure dbo.YourProcedure contains a loop that will attempt to process all the messages in the queue in a single execution of the procedure. In systems where each record has a physical file assigned to it, you can set up a trigger, and when the records are deleted, a SQL SERVICE BROKER message is sent containing the files that need to be deleted. A Windows service can then receive the messages in the queue and delete the physical files. The same can be done when files need to be moved from one place to another. When the record is updated, an update trigger on the table fires and sends a message to the SQL SERVICE BROKER. The message is then downloaded by a Windows service, which then moves the physical file. Many companies have all sorts of data logging going on either within the internal application, or within the web server to track site usage. This allows the web site to log data about the site usage, without having to wait for the database to process the insert or any rollups that are done based on the insert. . which end of the conversation can use which message type. The initiator of the contract is the sender of the message, and the target of the contract is the receiver of the message. Like the Message. to the SENT BY options in the exam. The various options can get confusing during the exam. Also pay attention to the wording of the questions. If you wish to create a contract that uses the. [YourApplication/YourMessageType] SENT BY ANY, ); Either syntax is perfectly acceptable, and neither is incorrect. There is no ALTER CONTRACT command in SQL Server 2005 or SQL Server 2008; perhaps this command will