Hero #18

Our Blog

Technical insight, ideas and commentary from IP HQ

Posted on 8 June, 2016 by David Edson

Leveraging BPM to Digitise Forms

Hands up those who think paper is an efficient information system? Time for a bit of Rock, Paper, Keyboards.

The IT industry has evolved over the last 50 years to provide automation and cost savings for the processing of information, in particular the concept of Business Process Management (BPM) has brought together the holy trilogy of Information, Procedure and Responsibility. In this blog I’m going to discuss how BPM can provide you with an effective paper replacement technology.

Posted on 30 May, 2016 by Kevin Henshall

Workday Technical Tip: One-Time Events

The Workday application takes a ‘fire and forget’ approach to integration that is not concerned about the success or failure of integration events with downstream systems. This can cause issues when synchronising employee data from Workday to other systems, particularly for one-time events.

Posted on 6 May, 2016 by Nirdesh Gupta

Getting Started With Your API Integration Strategy

Most people we talk to know that APIs can streamline integration and improve business agility. But with all the different products and approaches in the market, what they’re really grappling with is the best place to start and what technology they need to support their API strategy. In this blog I’m going to discuss the key areas you should focus on when starting down the path of API-led connectivity.

Posted on 17 March, 2016 by Riaan Ingram

Workday Technical Tip - Versioning of Web Services

When calling the standard out-of-the-box Workday web services, there are a couple of ways versioning can be approached. You can invoke a specific version of the Workday web services by adding a version attribute in the root element of the soap request payload e.g. bsvc:version=”v23” or you can default to the latest version by not entering a version attribute.

Posted on 9 March, 2016 by Kevin Henshall & Riaan Ingram

Importing types defined in an OpenAPI specification into Mule ESB

A mainstay of service-oriented integration is contract first design to accelerate development and facilitate a test driven development approach. When it comes to APIs the most widely accepted ‘contract’ definition standard is the OpenAPI specification, previously known as the Swagger Specification. In contrast the MuleSoft technology stack relies on the RAML specification, which is natively supported across its API Gateway and ESB products.

Due to the large base of tooling and community support that OpenAPI offers, you may prefer to make use of the OpenAPI standard to define your contracts instead of RAML. In this blog we will show you how to import the types defined in an OpenAPI definition into Anypoint Studio for development use in MuleESB.