Introduction
What is an Enterprise Service Bus?Why PHP?Why Blackbird?Why Not Blackbird?
Getting Started
PrerequisitesDownloading and Installing BlackbirdConfiguring an ESB InstanceRunning and Managing
Developing With Blackbird
Basic TheoryCallback FunctionsProtocol HandlersUsing Sandpiper
Use Cases
Stock Trading Grey BoxWeb Service IntegrationSales Order Integration

Sales Order Integration

[Graphics are coming soon]

Blackbird is especially well suited to component reuse. Assume an e-commerce environment that contains a Web store, an accounting system, and a CRM system. You want to notify the customer via e-mail whenever an order is placed/confirmed, and store the order in the accounting system, and a summary of the order in the CRM system. You could simply add code to the Web store to do this, but it's not very flexible today, or extensible down the road.

Blackbird ships with a demo module called email-sender. It is designed to send e-mail messages filled with fields from an incoming message in a message topic. To solve this problem using Blackbird, you could:

1. Create an XML Schema that defines a Sales Order, and describes header, line item, and summary information.
2. Create one Blackbird module for each of the three applications:
   • Web Store - Poll a database looking for new sales orders. For each new order, send an XML message to /topic/Sales/Orders that implements the SalesOrder schema with the Status field set to New.
   • Accounting System - Subscribe to /topic/Sales/Orders. Whenever a message is received, store the order in the accounting system, updating other tables if necessary.
   • CRM System - Same functionality as the accounting system, but a different target database and only storing a text summary description of the order.
3. Run a Blackbird instance with one instance each of the above modules. This provides the core integration functionality.

Once this environment is set up, adding an e-mail sender for customer order confirmations is as easy as making a configuration file that loads the email-sender object, tells it to listen to /topic/Sales/Orders, and provides the template files it should fill in for each new message.

Here's where reuse becomes valuable:

• Suppose you want to notify your sales reps when orders are placed, but only with summary information, not all of the details. Just configure another email-sender with the new recipient list and message template file - you're done in, well, how fast can you type?
  
  
• Now you want to send a notification to your upper management whenever there's an order placed that exceeds $5,000. Just add one more email-sender, using a template that tells Smarty to output DONOTSEND for orders less than that amount. The only code required is the if/then in the Smarty - one line, another configuration file, and you're done.
  
  
• Getting tired of e-mail? What if you want another accounting system. Not every day, but suppose you're migrating to a bigger or just better product? No problem, just run them both side by side, while you learn how to use the new one. If you write (or somebody has written) an integration module for the new product, both can listen to the same Sales topic(s) and receive copies of the same orders. Both will stay up to date during the migration.
  
  
• Next week, you need to set up some reports. Your accounting system provides some of what you need, but you don't want all of your users to have access to it, and you still need some things it doesn't provide. Write a module (it will only take a few lines of code, honest) that listens to /topic/Sales/Orders and dumps copies into a separate database. Then install Pentaho (or, gasp, Crystal Reports).

We could go on and on, but you get the idea - it's easy, and it's powerful.