Note

Although mentioned previously in this chapter, the following is so important that we restate it here:

As you use dynamic queues, channels, or components, you must indicate during development how its location can be determined. You do this on the Data page by connecting the message field that is expected to carry this information to the Port Reference field. The compiler checks if this is a feasible connection. If it is, the schedule drawing compiles nicely. However, during runtime, things can still go wrong if the queue name, channel name or moniker is incorrect; hence, not referencing an existing object. A way to prevent this is to add a component that can validate this value before you use it. In case it does not correlate to an existing queue, channel, or component, you can take control of the situation, without your XLANG schedule crashing because of the incorrect data.

3. Click Next, and you are prompted for a choice of queue (Figure 7.27):

■ Create a new queue for every instance The XLANG scheduler engine creates a new queue for every instance of this schedule. As the schedule ends, the scheduler engine removes the queue.When you choose this option, you have to enter the queue prefix that is made up out of the folder where the queues have to be created. By default, this is .\private$.This folder is a relative path from the directory where all the queues are stored. The queue name prefix is by default the port name.The XLANG scheduler will tag a unique identifier to it.

You want to choose this option if the schedule engine has to communicate with another application, where you send a message to the other application, or schedule informing it what queue to use. If the other party is also a schedule, it will have a dynamic queue port defined to use for this communication. For example, your schedule receives orders and has to check if the items are in stock. Therefore, it communicates with another schedule that can query the stock database. Since you want that "stock" schedule to send the information to the correct instance, it has to send it to a queue that is unique to this instance.

■ Use a known queue for all instances An existing queue, at least during runtime, is used and shared by all instances. If you select this option, you have to enter the full queue name; for example, .\public$\collectorqueue. Again, the compiler does not check if this is an existing queue. Double check for typos, or you might experience unexpected runtime errors.

There are two types of situation in which you can use a shared queue.Take the situation of a banking application, where the schedule has to process a money transfer. One action for all transfers is to update the bank's ledger.This is a central application, so each instance sends a message to the ledger's queue, and that application will take care of it. In the second situation, you have all the bank's branch offices make use of the same central application in the main office. Therefore, they all send their transaction messages to a central queue. You constructed a component to monitor the queue, and if the number of messages reaches preset thresholds, it will instantiate a new schedule to process the transactions. The processing XLANG schedule instantiations use a decision to keep reading messages from the queue, until it is empty. Once the queue is empty, the instance will end itself. In this case, you want the instances to also share a queue.

Figure 7.27 Choose Whether a Schedule Instance Needs a Private or Shared Queue

Figure 7.27 Choose Whether a Schedule Instance Needs a Private or Shared Queue

4. Click Next, which will bring you to the Advanced Port Properties page (Figure 7.28). It consists of two frames:

■ Security This has one or two options.The second option, Use a Windows Group or User Name to control the queue, is only presented if you defined this queue as static. It gives you the opportunity to determine which user or group is allowed to enter messages in the queue. So, what user/group should you enter? The most obvious choice is the user who runs the XLANG scheduler engine, since he owns the process that runs your schedule instances. Remember, the XLANG scheduler engine is a COM+ application, and every COM+ application is started under the security context of an existing user.Therefore, if you want to restrict access to the queue, you should enter the user that starts the XLANG scheduler engine, or in case you have more applications that host XLANG schedules, you can create a group for these users and enter the group's name. Be careful, since you have to enter the name manually and the compiler does not check if this is a valid name.Therefore, if you make a typo, no one is allowed to enter messages in the queue and the schedule will probably abort. If this happens, check the event log, and you should see an error message that explains your misfortune.

The other option, Sender identity conformation, is one we also saw in the other two wizards. It tells the scheduler engine how to handle sender identity:

a. Not required The XLANG scheduler engine will not attempt to establish the sender's identity, and the_Sender_

field will remain empty.

b. Optional The scheduler engine attempts to get a conformation on the sender's identity. In case it does, the identity is put in the_Sender_field. If the identity could not be established, the __Sender__ field remains empty, but the message is allowed through.

■ Required The scheduler engine must to be able to get a confirmation on the sender's identity. If it does, the identity is put in the

_Sender_field. However, if it is not possible to get that confirmation the message is not allowed through and the message is put in the queue .\private$\xlang scheduler.deadletter.

■ Transaction Support Has one option: Transactions are required with this queue.This option is directly related to the transactional setting of the queue. In fact, if the setting of both does not agree, it will result in a runtime error.You should use this option if the queue is part of a transaction.The scheduler engine will address the queue in a different way if it is transactional. Since it also means more overhead, it should only be used if necessary. Remember that an aborted transaction results in a rollback, meaning that the message in a transactional queue will be retracted. Indeed, it means that a message is only released by the queue if the transaction succeeds.

Was this article helpful?

0 0

Post a comment