Of the many BPMN shapes, I seem to get the most questions about the BPMN signal event. There seems to be 3 use cases that are the most common. But first let’s take a look at what the OMG BPMN 1.2 specification says about signal event:

Signal Event:

• Used for sending and receiving signals
• A signal is a generic, simple form of communication
  • Within pools (same participant)
  • Across pools (different participants)
  • Across Diagrams
• Has no specific recipient, meaning it could be received by any participant that is listening. (note that a participant could be a person, a system, or another process).
• The signal has a name
• Has attributes that further describe the signal
• Does not have a message body

Use case 1: Signal an unknown participant

Perhaps the most useful feature of the signal event is signaling an unknown participant. Often when I am in a store I hear an announcement “There is a car in the parking lot with its lights on”. Or sometimes I get an email asking “Who is working on the xxxx account?”. These are requests to get someone’s attention, but we don’t know specifically who the person it.

In the shopping mall example, we have a car with the lights on. The participants are the store(s) and the shoppers. We don’t know who’s car it is, so the announcement describes the car. So to model this in swimlanes, you would have these two participants. There are however a some problems with the swimlane appoach. First, you don’t know which of the shoppers the car belongs to. You must announce to every shopper. Second, you don’t even know if this is in fact a shopper that owns the car. The car could be owned by an employee, or it could be a shopper in another store. So the actual participant in this case is anyone that might potentially park a car in the store parking lot (potential car parkers).

An announcement for a car in the parking lot with its lights on

The signal event is also limited by the attributes “Black”, “BMW”, “Plate Number x12345″. So if I don’t have a black car I immediately ignore the rest of the message. Or if I have a black car but it’s not a BMW I can ignore this message. But if you have a black BMW and you don’t know what your plate number is, I’m assuming that you probably have some kind of subprocess for this. The point is, it is the responsibility of the potential signal receiver to identify its self and act accrdingly. Nobody is going to make you go turn off your lights. From the perspective of the store, they have fulfilled their obligation by making the announcement.

Note the usage of the group artifact shape (dash-dot-dash box around the signal events). This is used solely for style purposes and is not required according to the BPMN specification. Personally I have found it to be helpful when reading diagrams, similar to how punctuation makes it easier to read text. Case in point, if you notice the example below, it does not have the group artifiact shape around the signals. Your eyes must wander the diagram to find the matching signal receiver.

In the email example where someone is asking who is working on a particular account, again the signal is intended for anyone who might respond. We have potentially an account manager participant, or maybe it’s a customer service participant who gets a call from a customer but doesn’t know who the account manger is. In this case there is a message event (the email) but not necessarily. If the address is sent to a disribution list such as “all-account-managers” then this is more like a signal event than a message event. Yes, it is in fact an email message. It might even have a body attached. But who really reads these broadcast emails anyway? If you are like me you get 200 emails a day (on a slow day). I read the subject line and if it’s not interesting it goes straight in the trash. If someone is not smart enough to put the account number in the subject line which makes me actually read the message it’s not as efficient. So in the following example diagram we cover both cases, where the subject contains the signal attributes and the other case where I have to actually read the message.

Signal sent to find out who is responsible for an account

In theory you could use either a message event or a signal event for this example. The differenciation in this case is the fact that the sender participant might receive a response, but might not. The message body is probably empty in this case and the subject line might read “Who owns account number A12345″. If this isn’t my account I’ll delete the email it without reading it. Othewise I might want to do something before the customer becomes upset with me. The signal event simplifies this diagram because if I were to use a message event instead, I would also need several shapes to “filter” the message data to determine if it’s mine or not. Hence, the “is it for me?” gateway, which covers the case where someone didn’t bother to but the account number in the subject line and forced me to read the message. But if I know for a fact that all signals of this type will have the account number in the subject line, this is a true signal event and I don’t needt o evaluate if this is for me or not. This is because a signal event has an implicit filtering built-in. The inteneded process participant(s) must know their responsibility for receiving the message.

For persons not familiar with the notation, I chose to use an event driven gateway (the pentagon symbol insde the diamond) with two potential solutions to the problem of who owns the acocunt. In one case, someone will respond within a reasonable amount of time. In the other case, after a period of time has elapsed, I’m not going to wait any longer and take care of the custmomer myself.

Use case 2: Subscription

One good example I can think of for subscription is Twitter http://www.twitter.com . Email distribution lists are on the border line between what is a message and what is a signal. To qualify a form of communication to be a signal, it must be simple. Emails can contain large amounts of text, so they are not simple. Twitter is a site that allows you to broadcast some text (up to 140 characters maximum) to the world. Being that the messages are limited in size, they must be simple. To receive “tweets” (the broadcasts) on this site, you must subscribe to it. With no subscriptions, the “tweet” goes nowhere. Often the “tweet” goes out to everyone even though the message might be intended for just a few people. So again, the participant(s) must identify themselves and determine if the information is useful and relavant to their current process instances. In contrast, if I were to send you an email instead of broadcasting a tweet, this would indicate that I want specifically you to read it.

Another example of subscription is a stock symbol monitor. Stock prices are streamed over the internet. You can subscribe to specific events. For example I want to know ABC corp’s price. If I want to start receiving stock quotes, I simple “turn on” that stock symbol and the events will continue to stream until I turn it off. Whenever the stock market is open, the stock streamer simply sends the quotes, and doesn’t care if anyone is receiving them or not. Every stock symbol that has a price change will cause an signal event.

Signal event name: Stock Quote

Attributes: Up or Down, Price

Use case 3: Synchronization

In a large process with many participants, some processes require that some activities run in parallel, but must also be synchronized. For example, a procurement process where someone asks for some money but simultaneously starts to seek out a vendor. The vendor can be selected but the order cannot be placed until the funds have been acquired and transferred into the appropriate account. Let’s say that the vendor selection is handled by a special group of people. Being that it’s a group of people the originator might not know who exactly is working with the vendor(s). The order will not be processed until the signal to proceed has been sent. I might want to know about the status of the process as it progresses, but I don’t really need to know the full details.

I chose to use a signal event in this example for one specific reason: There are persons involved that were not introduced and potentially have no knowledge of each other. For example, the funds manager processes the request to transfer the money. Because the order manager is interested in this process instance, they can now proceed with the order placement. There is nothing in this process that says that the funds manager and the order manager are specifically aware of each other. They are in different departments and potentially these are different processes entirely. The only thing tying the process together is a common communication channel of some kind that has the ability to broadcast messages.

Synchronization accross multiple participants

In this example the loading dock receives a package. For the sake of argument, let’s say that the loading dock maintains a simple website that shows a tracking number and a date when it was received. If the Originator participant does not read this website regularly (the subscribe) then the package will remain in the receiving department indefinitely. It is in the interest of the originator participant to regularly monitor the status page to receive timely updates. Eventually the loading dock will delete the old messages. So if I don’t actively monitor the status page, I might not ever know the package was received.

Use case 4: Interruption

Interruption involves stopping multiple participants from performing their current activities, most likely because a major event has occurred that requires the process flow to change significantly. A simple example of this is when a customer is requesting a home mortgage loan. Mortgages are a complex process that requires many items on on checklist to be completed by multiple participants. Let’s say that the customer changes their mind and decides that now is not a good time to buy a home. Suddenly we have 10 people doing things for a process instance that no longer exists. We don’t want anyone to continue working on this process instance because it would be a waste of time. So a signal is sent, which would cause all interested participants to stop working on this loan.

Signal Event Name: Stop Processing

Attributes: Loan Number, Reason

Hopefully this post will help reveal the difference between a signal and a message.

Questions? Feel free to contact me.

Tags: BPMN