Phidiax Tech Blog

Adventures in custom software and technology implementation.

BizTalk Server: Connecting to Workday SOAP Services using the WCF Adapter in BizTalk

At a recent client, we were tasked with connecting to WorkDay and updating data in the WorkDay system. At its core, WorkDay uses SOAP and Rest Interfaces. For a bulk update, Workday implements a series of API calls that start with Import_xxx_xxx. These APIs allow bulk updates for large-scale operations. 

Now, how do we make this work with BizTalk? Here are the steps:

First, download the Workday WSDL for the package you want to work with. In our example, we will work with the Financial APIs. As in most SOAP-based systems, Workday exposes the WSDL for the service endpoints. For our system, we connected to:[tenantID]/Financial_Management/v30.0?wsdl

Note: Where N is your assigned implementation, Y is your services host, and [tenantID] is your assigned working tenant space.

Use the BizTalk Service Consuming Wizard to generate your WCF Connection Proxy.

Here we want access to the Import_Current_Conversion_Rates


Now we want to configure a Send port to send the data to WorkDay.

Initially, this looks like a standard SOAP 1.1 Send Port. Importing the non-Custom binding gives you a standard-looking WCF-BasicHttp Send Port.

However, WorkDay does require a few non-standard items, so you must edit the WCF-BasicHttp Transport Properties.

First, it requires a User name and Password.  The User name must include the tenant ID after the username: username@TenantID

On the Security tab, change the Transport Client Credential type to Base. Click the Edit button in the Client Credentials area.

Unfortunately, this will not be good enough. At this point, we get the following error:

Error details: System.ServiceModel.Security.MessageSecurityException: Security processor was unable to find a security header in the message. This might be because the message is an unsecured fault or because there is a binding mismatch between the communicating parties.  This can occur if the service is configured for security and the client is not using security.

Initially, we thought we had a problem with the security settings. But after a review of the stack trace, this stood out.

Exception rethrown at [0]:
At System.Runtime.Remoting.Proxies.RealProxy.HandlReturnMessage(IMessage reqMsg, IMessage retMsg)

Suddenly it dawned on us that Workday’s response was invalid because the response from Workday didn’t include the normal security response in the header.

In the <security> node of the WCF Transport, there is a setting called "enableUnsecuredResponse", and we needed to support this element. When we reviewed the WCF-BasicHttp profile AND the WCF-Custom profiles, it became apparent that neither of these profiles exposed that security element.

So, we have to use the WCF-Custom binding with the customBinding binding type. Inside of the customBinding binding type, we must override several of the default values. The UI doesn’t give access to default values, so we have to export the binding from the editor, hand-change the values, and then re-import the binding.

You must update the messageVersion in the textMessageEncoding. This is the default for the WCF-Basic profile, but not the default in the binding.

Finally, we updated the credentials and started the Send Port. We were able to send messages to Workday with no custom coding or adapter, by changing the WCF configuration to conform with the Workday requirements.


Privacy Policy  |  Contact  |  Careers

2009-2017 Phidiax, LLC - All Rights Reserved