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:
https://wdN-impl-servicesY.workday.com/ccx/services/[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.
2009-2017 Phidiax, LLC - All Rights Reserved