In the first part of this post we show how to start an Activiti process from Mule ESB using the new Mule’s activiti module. In this part we are going to show how to call a Web Service from Activiti that is going to be contained in Mule. Notice that you can expose anything as a Web service in Mule such as: beans, queues, etc.
First of all we need to create our proces.
How much time do you invest in estimating your backlog? Do you really get any value from it? When was the last time you thought about the value it provides you? I can see estimation as a source of problems in many ways.
We are pleased to announce Mule 3 Activiti support. We’re very happy to be working with the Activiti team and see a lot of value for our community using Mule and Activiti together. I already discussed why BPM and ESB need to work together and two different uses of ESBs with BPM. Today I am going to present a real world example.
For those that may not be familiar,
There is no denying it, the cloud is having a massive impact on all our lives. In the enterprise many of the applications that we to host in our own data centers now live in the cloud. We are a fairly typical company in terms of our IT, we don’t host any business software in house. We use Google Apps, Salesforce, Intaact, Marketo, and more. We do it because it is convenient,
One of the enterprise integration patterns that Mule hasn’t explicitly supported up until now is the “Content Enricher”. Enrichment has of course been possible but it hasn’t been as easy as it should have been. That’s changing for Mule 3.1 as we introduce support for message enrichment. Read on to learn what you can do with the new enricher and see some examples..
On my previous post about Kanban, I presented the challenges we had in our Engineering team. They were:
1. Uncontrolled growth of Work In Progress.
2. Not Enough visibility.
3. Reduced quality.
4. Inability to properly estimate all tasks upfront.
5. Planned features and improvements are hard to manage and implement.
During the implementation of Kanban we focused on solving those problems.
Being able to publish and subscribe to event streams is a powerful enabler for business activities. As business rules change and systems evolve, the low coupling that is inherent to this integration pattern allows an IT landscape to evolve gracefully.
Imagine, for example, that you need to perform several independent actions whenever a user signs-up to your site (like: create an account, register to a marketing mailing list, warm-up caches…). A good design would be to have these different actions performed by different systems acting upon receiving their marching order from a central place where “new user sign-up” events would be published to.
Messaging systems used to be found only in big enterprises or in the financial sector. Who else needed the reliability and scalability offered by such systems? But times have changed: public web sites have grown to sizes that dwarf some of the most advanced corporate systems. And as these web sites have grown, the need for timely decoupling their subsystems in order to scale has increased to.
This lead an entirely different breed of developers to want messaging systems too.
Often I get the following question. Should we solve this integration problem using and ESB, using BPM or both?
There is no unique or simple answer to that question, because it depends on the use case. But there is definitively a place for ESB and a place for BPM and they can and should leverage each other. Let’s take a look at how to answer the question above.
I read a couple of RSS feeds regularly. Unfortunately, I work across a couple of machines: my laptop, the machine in the office, my wife’s laptop. This rules out using a local RSS reader as I’d have to manage the redundant subscriptions let alone I’d have to remember which feed entries I have already read and which one not. Sure, I could use Google’s feed reader but being mostly eMail centric anyway I’d love to see RSS feed entries in my INBOX.