A new Mule release has to come with another internal hackathon. Our development teams focused on using the new features we added in Mule 3.3 and we came to the conclusion “A hackathon is like a box of chocolate, you never know what your are gonna get”. In our case, we got some really cool applications, so cool that some of those can become real products in the future.
We had 7 teams participating and here is a description of what they created in just a few hours.
The “moving-the-needle-synergy center of excellence” team re-implemented an existing application developed for a client, the “Ultimate enterprise scheduler“. This application handled scheduled request to trigger a synchronization of accounting transactions between two systems. Reimplementing this real life application gave us a lot of feedback of what the new Mule features means in terms of simplifying the code. They found using the new 3.3 features, like Data Mapper in Studio and the new for-each, error handling and set payload, they reduced in 80% their custom Java code to solve the same problem. It also reduced the time to develop the same application to half of what it took them the first time.
The “DataNapper” team implemented “Skypenet“, an interactive assistant over Skype. They created a new Skype connector, which allowed them to take commands through an Skype chat, giving you access to any data repository. For example they used the GetSatisfaction connector, so you could search in Mule forums by just typing in your skype chat, and the assistant searched on the forums and returned links to all the threads matching your criteria. You could also request Mule artifacts with another command. A command like “@download mule-core” will make the assistant review our maven repository and send you the latest jar for that artifact, in our case the 3.3 version of it. To improve the performance, they used the new cache in 3.3 improving the response time as more people requested the same things.
The “No Idea” team implemented a “Repository” with a rest interface. It allowed you to store resources (jars, wsdl, templates) in a DB through a Rest interface. Then you could search, update and delete them maintaing the version and the information of the resource. Now to make it more interesting, the team implemented a notification mechanism, which maintained updated any client connected to the registry through JMS.
The “Win or Quit” team created a “SAP web service gateway”. They wrapped SAP functions using the Mule SAP connector allowing you to expose that functionality as SOAP based web service allowing you to setup security using SAML. It’s a great idea and multiple people will find this really beneficial, in particular to expose SAP functionality in a flexible and secure way outside of your firewall.
The “I’m IronMan” team created an application named, “Google and Salesforce secret romance”, using the new Google API connector and the Salesforce Connector. You created a list of contacts in a google spreadsheet, then import those contacts from the spreadsheet into Salesforce as contacts. Then from Salesforce, you create appointments in your google calendar for those contacts. It was great to see that level of integration between cloud services, all handled by a few Mule flows.
The “Mini-me” team created the Jirhub application. It’s based on a previous hackathon winner application which integrates Jira and Github projects. They extended it to make it configurable allowing you to map multiple Github projects into one Jira project using the components as the way to group them. That way when you close an issue in Jira, it will close the issue in Github, and viceversa. This application will keep in sync everything, including the comments.
The “Ding!” team created the “Ding!” Application. This was interesting, because the team used an emulator of the Raspberry PI to run Mule on a small computer which costs 25 USD. Running Mule on a small box opens a long list of possibilities. In their case, they implemented a distributed gong. They connected a central Mule to Salesforce to receive through streaming notification when an customer ticket is closed. That central Mule had a list of registered Mule running on small boxes, and notified them through JMS. Then in those small boxes they run custom code written in Java to play different sounds on the remote offices to celebrate the close of a ticket. We will actually implement this distributed notification boxes in the future to let the different offices know when the build is broken or when a new deal is closed. Keep connected to hear more about this.
We hope this applications open your mind to new ways and you can write your own innovative Mule 3.3 applications. We want to hear from those ideas, and we might do them in the next hackathon!.
