SaaS applications like Salesforce have proven to be highly disruptive for many .NET architectures. In this multi-part blog series, we’ll demonstrate step-by-step how .NET-centric organizations can use existing assets (e.g. legacy .NET applications, SAP) to maximize the value of their Salesforce investment without disrupting underlying code.
In Part 1 of this blog post series we will explore a scenario that has an Auto Insurance company building quotes that allow customers to evaluate their premiums. As part of this process there are some complicated quote calculations that must take place. These calculations take into consideration a customer’s age, driving record, level of education and location. These calculations are proprietary to the organization, provide a competitive advantage and have broad impacts if mistakes are made while building the calculations in the Quote system.
A good part of the Mule community has learnt to use Mule with the first edition of Mule in Action. With the advent of Mule 3, there has been huge demand for a book covering the latest improvements, best practices and lessons learned in the trenches.
In 3.5 we introduced the concept of domains in the Mule container. You can now set up a domain and associate your Mule applications with a domain. Within a domain project you can define a set of resources (and the libraries required by those resources) to share between the applications that belong to the domain.
Within the mule-domain-config.xml you can define a JMS broker connector that can be reused by all the Mule applications that belong to that domain.
This way, you can share a jms caching connection factory and reuse jms client resources with the consequent optimization of resource consumption.
Here’s our weekly roundup of the top 5 integration and API articles of the week. Take a look, let us know if we missed any, and share your thoughts in the comments. Don’t forget to follow @MuleSoft to stay up-to-date on integration & APIs!
If you’re interested in Integration and APIs, don’t miss CONNECT 2014 – the event behind the integration revolution!
Connecting Mule application to Zuul server requires two additional jars in the application class path. One of them is jasypt library which can be downloaded here. The second one is zuul-spring-client. You can download the source and build the jar using Maven.
To configure Zuul client, first add zuul namespace to the mule tag. You will also need spring and context namespaces.
Next, configure zuul spring bean and spring context referencing this bean:
It is always recommended to use Spring properties with Mule, to externalize any configuration parameters (URLs, ports, user names, passwords, etc.). For example, the Acme APIfrom my previous post connects to an external database. So instead of hard-coding connectivity options inside my application code, I would create a properties file, e.g. [[code]]czoxNTpcImFjbWUucHJvcGVydGllc1wiO3tbJiomXX0=[[/code]], as follows:
Obviously, as a developer, I would use a test instance of Acme database to test my application. I’d commit the code to the version control system, including the properties file. Then my application would begin its journey from the automated build system to the Dev environment, to QA, Pre-Prod, and finally Prod – and fail to deploy on production because it wouldn’t be able to connect to the test database! Or even worse, it would connect to the test database and use it and no one would notice the problem until customers placed $0 order for an Acme widget which would normally cost $1000, all because the test database didn’t contain actual prices!
Media companies, postal services, newspapers and other print publishers have been talking about monetizing digital assets both to create new revenue opportunities and, quite frankly, to remain relevant in the age of the digital prosumer.
New Zealand Post has embarked on a project to unlock their digital assets with APIs to create brand new revenue streams through their affiliate and partner networks. We will feature their story as one of many exciting use cases during MuleSoft’s inaugural conference – CONNECT 2014 in San Francisco, May 27-29th.
We’re excited to count Salesforce, Tesla, and Box – amongst the most innovative companies in the world today – as our customers and feature their transformational CIOs – Ross Meyercord, Jay Vijayan, and Ben Haines – in our keynote sessions to discuss how each in their own unique way is fundamentally changing business patterns by becoming a Connected Company.
The author described something called Smart Dust. Tiny microscopic sensors floating through our cities, tracking and collecting all kinds of data.
“He and his team use Dust, portable packets of sensors that float in the air throughout the entire city and track movement, biometric indicators, temperature change and chemical composition of everything in their city.“
The best things in life are often sweet and simple. However, “S & S” is an easy concept to understand and appreciate but often hard to implement. For example, a sweet and simple way to attract traffic to our blog would be to show women in bikinis playing with cats. In reality that is rather hard to pull off for a technical site. There simply is no budget to publish anything like “API Illustrated, Swimsuit Edition” or “ESBN, the Body Issue”. Instead, this article will focus on sweet and simple features in our products that can make life easier for integration developers.
With 100,000+ customers, Salesforce.com is one of the most popular integration endpoints for ESB implementations. There are a couple of commonly asked questions when it comes to Salesforce.com: how do you reduce the number of API calls since there are daily limits per instance, and how do you retrieve all the related records in one query? The SOQL Relationship Queries help accomplish both goals, as a developer can make just one API call against different SObject types that are also related.