So you have written this new cool service (hopefully using Mule), and you even develop an insanely great iOS app to complement your new cool service. In todays article I’m going to show you how you can make your service even more awesome with Mule Cloud Connect by allowing your service to send push notifications to your iOS app.
What is Mule Cloud Connect?
Mule Cloud Connect is a technology part of Mule ESB 3 release,
When your test base can be measured in tens of tests (or more) you should pay attention to bests practices and design principles if you want a highly maintainable code, quite resistant to technological changes, changes on the UI, etc. This article introduces Page Model pattern that is a great help in that regard.
The service framework in Mule has always existed for building integration solutions. The design is simple and highly scalable: 1) messages flow in on a channel to an inbound endpoint, 2) transformations and filters are applied (if necessary), 3) the service component processes the messages and, finally, 4) the outbound router sends them on their way to the desired outbound endpoint (again, applying any transformations or filters as necessary).
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,
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.
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.
Why are GUI integration tests needed? On which testing tool technology should I base my tests? What are the cost/benefit of the choosing one over the other? In this brief article we will give you a quick look at the answers to those questions.
Here at Mulesoft, we use Jira for a lot of different things: tracking hiring, IT tasks, reporting product bugs, planning releases, etc.
We recently upgraded our Jira instances to the latest 4.2 version. One of my favorite new features is the ability to create your own search query in a SQL-like syntax. This allows you to customize your searches in all new ways. For example,
Mule 3.1 introduces a very useful new <logger> element that makes it easy to inspect the content and properties of your messages in Mule while building or debugging a flow. It’s also perfect for logging errors, info messages etc. Mule has always supported logging with the <log-component> but while working with the new orchestration capabilities of Mule 3 flows, we found a real need for fine-grained logging. With the new message processor architecture,
In order to use the hot deployment feature that was introduced with Mule 3 you need to package your application as a zip file.
If you are using Maven to build your Mule applications then packaging zip files for hot deployment is very easy. All you need is to declare your packaging to be Mule: