OData for Pragmatists

Reading Time: 5 minutes

Tired of googling and reading about OData without having a chance to play with it? Get happy then, this post is for those pragmatics like me that enjoy learning by doing rather than dealing with theory. If you enjoy the trial and error process, I can assure you that you won’t be disappointed.

What is OData?
Open Data Protocol (OData) is an open protocol to allow the creation and consumption of queryable and interoperable RESTful APIs in a simple and standard way. It defines an abstract data model (EDM) and a protocol (based on REST) that let any client access information exposed by any data source.

The anatomy of an OData service
A URI used by an OData service has up to three significant parts: the service root URI, resource path and query string options.

Screen Shot 2015-07-31 at 5.21.49 PM

The Service Document
The Service Document is a list of all the top-level entities and is typically available at the Service Root URI.
ex. http://services.odata.org/OData/OData.svc/

Retrieving entities and their properties
Retrieving entities is simple, just add the entity type to the URI
ex. http://services.odata.org/OData/OData.svc/Products

A single entity can be retrieved through its key.
ex. http://services.odata.org/OData/OData.svc/Products(1)

A query can be refined as much as needed to retrieve related entities:
http://services.odata.org/OData/OData.svc/Categories(1)/Products(1)/Supplier/Address/City

Counting the entities
Counting the entities is as easy as adding the $count suffix to an entity URI.
ex. http://services.odata.org/OData/OData.svc/Products/$count

Retrieving the metadata
The metadata model can be retrieved by adding the suffix $metadata to the URI
ex. http://services.odata.org/OData/OData.svc/$metadata

Formatting the response
With the exception of the metadata of the service (which is expressed in CSDL), all responses may be formatted in Atom or JSON, either by using the $format=json or $format=atom options or by setting the “Accept” header (i.e. “application/json”). The default is Atom/AtomPub.
ex. http://services.odata.org/OData/OData.svc/?$format=json

Querying the service
To query the service, the following options can be combined to refine the search:

$top=n: Returns only the first n entities in an entity set (or in Atom terms, the first n entries in a feed).
ex. http://services.odata.org/OData/OData.svc/Products?$top=2

$skip=n: Skips the first n entities in an entity set. Using this option lets a client retrieve a series of distinct pages on subsequent requests.
ex. http://services.odata.org/OData/OData.svc/Products?$skip=2

$orderby=: Orders results, in ascending or descending order, by the value of one or more properties in those results.
ex. http://services.odata.org/OData/OData.svc/Products?$orderby=Name desc

$filter=: Returns only entities that match the specified expression.
ex. http://services.odata.org/OData/OData.svc/Products?$filter=substringof(‘Ounce’, Description) eq true

$select=: Returns only the specified properties in an entity.
ex. http://services.odata.org/OData/OData.svc/Products?$select=Price,Name

$expand=: identifies the Collection of Categories as well as each of the Products associated with each Category.
ex. http://services.odata.org/OData/OData.svc/Categories?$expand=Products

These operations can be combined to form complex queries, like
http://services.odata.org/OData/OData.svc/Products?$top=20&$skip=2&$select=Price,%20Name&$orderby=Name%20desc&$format=json

Conclusion
As you have seen, consuming an OData service is simple and yet powerful.
Hope you enjoyed this post, see you soon.

P.S.: This is not meant to be a comprehensive description about OData (for that you can find proper documentation here).

Batch Module: Obtaining the job instance id in Mule 3.7

Reading Time: 3 minutes

A popular request among users of the Batch module is the ability to grab the job instance id in any of a Batch job’s phases. Why is that useful? Well, there could be a number of useful scenarios:

Continue reading

Create Better Business Strategies with Real-Time Customer Intelligence

Reading Time: 3 minutes

Who are your customers? How can your business develop rich and deep relationships with them? We talk about using customer data in order to establish a single view of the customer; is your infrastructure equipped to collect and orchestrate all the relevant data in order to become truly customer-centric?

Customer data is complicated. It lives in multiple places, is generated at every touchpoint (not just sales), and changes frequently. Creating a holistic view of the customer journey can be a challenge, but one that can be solved with the right IT architecture. On July 30 at 10 A.M. PDT MuleSoft is presenting a webinar with Larry Drebes, the founder and CEO of Janrain. Join us to find out how to make customer data actionable for your business, the benefits of managing customer identity in the cloud, and to hear lessons learned from thousands of enterprises.

Janrain’s Customer Identity architecture is built with MuleSoft’s Anypoint Platform, which has had numerous benefits. Using MuleSoft has reduced the time to build new connectors by 80%, expanded the developer community for Janrain developers, and has made re-use of connectors easy, which allows developers to identify patterns that can be used for additional customer data. Working with MuleSoft allowed Janrain to launch more than 20 integrations in the first two months, which provides Janrain’s customers with more business intelligence.

In this webinar, you’ll learn:

  • How to integrate customer data within a cloud environment using MuleSoft
  • The history of data integration architecture including: integration phases, requirements, rationale, limitations and implementation, and why Janrain ended up selecting MuleSoft for this functionality
  • Example connections and systems

If becoming more customer-centric is important to your company, this webinar is for you.

How to Succeed at Digital Transformation: Connect the Unconnected

Reading Time: 8 minutes

At industry conferences, in boardrooms, blogs and PowerPoint decks, the new corporate obsession is rapid “digital transformation.” According to KPMG, 93 percent of multinational companies are overhauling their business models. They have to. They realize that customer demand is evolving faster than they can adapt. They see they need to accelerate product development, reach buyers on mobile devices and analyze real-time data from storefronts and warehouses. Essentially, they need to act like much smaller companies—the kind that can turn on a dime. For the Fortune 500, where ‘real-time’ can mean ‘sometime this quarter,’ that’s a serious transformation indeed.

The challenge they’re up against is to connect the unconnected. The more effectively they can combine applications, data, clouds, supply chains and partner ecosystems, and the more services they can create for outside developers, the faster and more agile they become, and the better they can compete. It’s not theory. They’ve seen the evidence.

Take airlines, for example. In the past, each airline had its own walled-off system for tickets, reservations and seating. Now they make all that data available to partners like Kayak, Expedia and Hotwire to drive customers to their flights.

Why? Because connectivity is the new path to revenue. Any airline that didn’t provide data to companies like Expedia could never stay in business today. And for its part, Expedia doesn’t just consume data. It generates more than $2 billion annually from partners of its own, who pay to access its listings. Take another example: Salesforce, gets 75% of its revenue from connected services.

Big, traditional companies desperately want this kind of transformation, but they crave stability. Increasingly, the way they get both is by turning to APIs.

The term ‘API’ might sound like technical jargon, but it’s actually a simple concept. It’s software that other software can use to access applications, data or infrastructure, like storage or network resources. Think of an API as a power socket for digital products and services. Your product might be a mobile app for customers, partners or employees, a B2B exchange, a connected supply-chain, an affiliate-network or website. Any of them can request what your API provides and be sure of getting it.

APIs are much more than a way to provide access to services. They’re a way to change your business without disrupting it. Suppose you develop a sales app, which accesses an important customer database. The salespeople use the app to do their jobs. They want it to keep improving. IT wants to protect the database. They don’t want developers mucking it up. The upshot? Gridlock.

Organizations often resolve this dilemma by having IT approve (or worse, help design) each new version of the app to make sure it doesn’t damage the database. You can imagine how much time and effort that wastes. A much better approach is to create an API that gives the mobile developers just the data access they need. That way, the developers can experiment to their hearts content, and IT can rest easy, knowing nothing will happen to the database that they haven’t authorized.

The same principle applies throughout the enterprise. When it comes to digital transformation, direct connections are your enemy. They slow you down. They break your workflows. They lock you up. APIs give you a flexible way to manage interactions between your legacy IT—procurement, financials, personnel—and your fast-changing front-end applications: mobile apps, analytics, business exchanges, and everything in between. Your end users get newer and better services, while IT maintains control over your systems of record. That way, your business can move fast without endangering security or data governance. If you’ve heard of “bimodal IT.” [Bimodal Business leads to Bimodal IT], this is what it looks like.

Uber, for example, was able to expand to 54 countries in three years because it made its back-end connectivity available through APIs. From a technological perspective, rolling Uber out in a new country simply meant switching on a new currency and modeling new billing rules in the back-end systems. Uber expanded its business into tens of new markets just by tweaking its app.

Make no mistake: successful revolutions take planning to pull off, and a digital transformation is no exception. The good news is, transformation can happen incrementally. You must think big, but you can start small. The key is to have a plan for your first APIs and how they connect. Then start building. You’ll learn how to do it, and pretty soon you’ll want more. Just begin. You have nothing to lose but your grey flannel suit.

Anypoint Platform API offering – June 2015 release

Reading Time: 9 minutes

Anypoint Platform API offering – July 2015 release

I am happy to announce that as part of the Anypoint Platform June launch we introduced the following Anypoint Platform API offering capabilities that together enable significant efficiency and user experience boost for Anypoint Platform users.

Let’s dig into each of these areas.

Single-click hybrid API management

API owners want to have a way to expose their new or existing APIs through an API management layer with the least amount of work required. API program owners, that is the architects and administrators who typically own the API management services made available within an enterprise, want to ensure that APIs that are exposed are done so in a well governed manner: The Anypoint Platform has always provided strong capabilities to enable the goal of these stakeholders. The new single-click hybrid API management capability makes these stakeholders even more efficient.

One-click auto-deployment of API proxies to cloud API gateways was introduced back in February. In this release, we take this capability further by extending support to on-prem API gateways. API program owners can now make both cloud based as well as on-prem based gateway instances available to specific business groups and environments for their use. API owners can then choose any of the available gateway instances to proxy their APIs for management. With a single click, a proxy is then generated and automatically deployed to the target API gateway server of choice in a given environment.

The gateway servers, API proxies, their environments, and business groups are all managed through the new Anypoint Management Console with the benefit that all users, roles, fine grained permissions, and business groups for an organization are honored to enable a well governed process for the management of APIs and their underlying infrastructure.

Of course, users will have the choice of bypassing the one-click deployment and choose a manual “download then deploy” process instead – this is typically the path of choice for customers who want to introduce internal workflow controls on the management of APIs or require the modification of proxies to introduce more complex business logic through the power of Mule message processor components.

External Anypoint Enterprise Security OAuth support

The Anypoint Platform has always supported the securing of APIs through OAuth. Support for this functionality has been possible through MuleSoft’s own Anypoint Enterprise Security (AES) OAuth server as well as through OOTB integration with PingFederate and OpenAM. This release extends the capabilities of our AES OAuth support by allowing for AES OAuth servers to be configured on stand-alone API gateways as opposed to having the servers be configured within the proxies themselves as was previously supported. The diagram below illustrates the high-level inner workings of this new functionality.

anypoint-platform-api-offering-june-2015-release2

This new capability is powerful as it enables the separation of concern between the management of OAuth servers from that of API gateway servers. Typically, these servers are managed by different groups and have their own lifecycle cadence. Furthermore, AES based OAuth servers can also be used in combination with PingFederate or OpenAM based servers – something that administrators might want to consider for high scale configurations where many different environments exist and where the lighter weight AES OAuth server is sufficient for non-production environments.

API Portals support for images and file attachments

The Anypoint Platform Portal capabilities are designed to allow for rapid creation of a highly efficient API engagement layer in a high scale setting: Environments where 100’s if not 1000’s of APIs are present and need to be exposed with efficiency and consistency. In this release of the Anypoint Platform, we have furthered this aim with the introduction of the capability for API portal publishers to be able to add images and file attachments to the content of an API portal, as opposed to having to store the content separately and link to it.

Note that this capability is currently in beta as API version exports do not contain file and image attachments and images cannot be resized. We plan to promote this feature to GA in short order after addressing these two remaining areas.

New API management policies

And one just more thing… by leveraging the Anypoint Platform custom API policy framework, we have used the power of Mule integration components to build 11 new custom API Management policies. We have published these policies on Anypoint Exchange so that they may be leveraged for adoption by our customers – treat them as starting points and use/evolve them as you see fit.

anypoint-platform-api-offering-june-2015-release3

The exchange directory has all of the details, but at a glance, here are the general areas that these policies cover:

  • Message logging – Toggle header, payload, and/or analytics logging on a given API version with resource/method level filters.
  • Transformation – Use the Mule Expression Language or XSLT to transform API requests and responses.
  • Message filtering – Filter access to an API based on a Mule Expression language filter.
  • Response caching – Decrease load and save cost on the calls to the backend APIs by using a cached version of a response.
  • SAML and WS-Security – Covert from SAML to basic auth and vice-versa, or validate the WS-Security SAML assertions of incoming requests,

This concludes the overview of the exciting new capabilities that we have just introduced into the Anypoint Platform. Stay tuned for more to come!

Monitor RAML APIs with API Science

Reading Time: 4 minutes

At MuleSoft we truly believe in the power of RAML as a contract for APIs. RAML allows teams to quickly and easily define, build and collaborate on APIs. Our Anypoint Platform for APIs is built from the ground up to easily manage RAML based APIs by providing a simple RAML API proxy as well as an easy to use RAML API Console.

Now, we’re excited to see that the ecosystem for RAML-based tools continues to grow. API Science has launched a RAML import feature for their API monitoring service. This new feature allows users to import a RAML from either a URL, file or YAML and then monitor for uptime and performance over time.

raml import 1

For Anypoint Platform APIs you can import a RAML in two ways. First, you can export the RAML file(s) directly from the API Designer and then import them to API Science. Second, you can use the RAML link displayed at the bottom of the API Console as shown below.

raml import 2

Once the RAML has been imported to API Science, users will recognize the standard RAML API Console for trying the API. What’s new, however, is the ability to monitor individual resources and methods. As shown below you can monitor the GET method on this specific resource of an API.

raml import 3

Once a monitor is setup, API Science will watch that API from monitoring stations around the world. This gives you powerful tools including an API health dashboard, API-aware validations, scriptable multi-step monitors, and a an alert rules engine so that you know before your customers do if anything goes wrong with your APIs or the APIs you rely on.

raml import 4

This is another great example of how RAML provides a simple and succinct way of building & managing great APIs. Not only is it easy to build and manage these APIs with the Anypoint Platform for APIs it is now just as easy to monitor those APIs once they’ve been deployed using API Science.

To get started managing your APIs you can visit https://anypoint.mulesoft.com. To learn more about API Science or RAML you can visit them at https://www.apiscience.com or http://raml.org.

Introducing Pub/Sub Pattern for Anypoint Templates

Reading Time: 7 minutes

Anypoint Templates showcase best practices around most common data integration patterns between two systems, for example, Salesforce and Workday, Salesforce and MS Dynamics CRM, Salesforce and NetSuite, Workday and ServiceNow and so on. With our new series of Pub/Sub templates, implemented using a publish/subscribe architecture, we are providing a more modularized approach to integration by allowing you to decouple source and destination systems and easily incorporate multiple systems without having to modify the existing integration application.

Continue reading

Refactoring MUnit: the Mule testing framework

Reading Time: 4 minutes

 

A few years ago, a MuleSoft engineer had a vision. That vision: automated testing for Mule applications in Anypoint Studio. As this developer’s focus was building Mule applications to connect SaaS apps, a validation framework would significantly reduce development time and increase productivity across teams. More specifically, unit tests would allow this developer to mock dependencies, uncover problems early, refactor applications quickly, and provide agile documentation for other Muleys. Months later, MUnit was born.

MUnit is the Mule testing framework. It allows developers using Anypoint Platform to code functional, integration, or unit tests for Mule applications through an intuitive API fully integrated with Anypoint Studio. Once developed, these tests can be isolated, debugged, and automated from Anypoint Studio to maximize development productivity.

refactoring munit 1

MUnit tests can be written in Java or Mule, and MUnit is fully integrated with Maven and Surefire for extensibility into your continuous integration environment. With MUnit, a number of flow elements can be enabled, disabled, and mocked:

  • Enable/Disable Inbound endpoints: HTTP, JMS, FTP/SFTP
  • Mock Message processors (MP): any Mule component that is not a router, scope or filter (e.g. Anypoint Connectors, transformers)
  • Mock Outbound endpoints: JDBC outbound endpoints, HTTP outbound endpoints

Within an MUnit test suite, developers have access to a full suite of testing tools

  • Assertions for Mule messages to ensure the Mule message is what you expect
  • Mocking of components inside a Mule flow (the service doesn’t need to be running in production)
  • Verify calls and test the # of times an MP has been called: exactly one, at least #, at most #
  • Spy on an MP before/after execution: Inspect the Mule message before/after calling a MP
  • Set up and tear down sections for test suites
  • Custom Assertions: extend framework as you see fit (e.g. complex validation)
refactoring munit

MUnit will be available in early July, featuring a significant upgrade to the previous MUnit Message Processing language, better integration with Anypoint Studio, and an expanded set of components to run test against. If you are eager to start playing with it, and can’t wait for the official release, you can go to the GitHub page.

We’ll be covering more of the basics of MUnit and working through a series of more advanced use cases in coming blogs. Let us know what you think on the forums!