Basics : Using SOAP UI

Soap UI is a open source functional testing tool for API Testing. It supports multiple protocols such as SOAP, REST, HTTP, JMS and AMF. It is available in two editions, one is a free open source version and the other is Pro version which you might have to pay for the license. I use the free open source version as I never had the reason to upgrade for a pro. You can download it from their official website (http://www.soapui.org/Downloads/latest-release.html)

I have only used this tool only to test SOAP and REST protocols. Once you are done with installing the tool, we will get started.

The home screen should look something like this

We will try to invoke a SOAP based web service in this article. 

Go to the File on the menu and click on new SOAP project.

Enter some project name and copy the http endpoint with suffix '?wsdl'. This should open a set of web services on the left pane(Navigator) depending on the WSDL that you provided.

Click on the particular web service that you would like to call. You should see a Request that you can open and edit before hitting the server.

 If you hit the server, it should error out as you did not provide any authentication details. For this you need to add an authentication block to the SOAP header. Go to the Request Properties tab on the left bottom and add the authentication details by doing as shown below.

*** For accessing workday webservices you should include the tenant name in the user name. For example if I want to invoke a web service for tenant 'abcd1', then username will be 'vinod-impl@abcd1'

Now mock the web service and play with it. Happy Testing :)

I hope this tutorial helps you. Feel free to leave your feedback in the comments below.  

All About : SOAP

In this post, let us try to explore more about SOAP which stands for Simple Object Access Protocol. This is one of the ways of protocols used for coding web services. Please read through my earlier post(Must Know Basics: Web Services) on web services to get a background on this topic.

SOAP is simple and open standard XML based communication protocol for exchanging information between applications. SOAP uses HTTP (Hyper Text Transfer Protocol) as a transport protocol.SOAP provides a way to communicate between applications running on different operating systems, with different technologies and programming languages.

A SOAP message is an ordinary XML document with the following elements:

* Envelope (mandatory)- defines the start and end of the message

* Header   (Optional) - contains header information and provides optional attributes

* Body     (mandatory)- contains the call and response information

* Fault    (optional) - contains status and error information

WSDL (Web Service Description Language) is a common temr that you hear around SOAP. I would like to give you the basic idea of WSDL before we talk more about SOAP.
* WSDL is a simple XML document which describes a web service
* WSDL is a W3C recommendation
* It is also used to locate web services
If you have a web service endpoint, you can extract the WSDL using a web service testing tool. WSDL will give you a basic idea on how the request and response look like and other informaiton like the data types that can be passed in various attributes and parameters in the SOAP request.

Here is the simplified fraction of a WSDL document.

Below is a skeleton SOAP message

Let us try and invoke some sample SOAP based web service from this page http://www.service-repository.com/

Before that you need to know how to use SOAP-UI (Web Service Testing Tool). If you do not have idea on this, I would suggest you to go to the link..

I've picked up a SOAP service which gives you weather information of a city by taking the ZIP code as input.

Here is the SOAP request:

Response:

I hope this gave you a better understanding of SOAP based web services. Please feel free to write to me or leave your valuable feedback in the comments.

My Favourite : Workday 23 Feature

You all know Workday has comeup with the version 23 update last month. Of all the new features that offers, my favourite feature is "Check Print Configuration using BIRT".

I would like to go a little futher to show you how much impact it will have on a person working for a Workday Payroll implementation. When you have workday payroll implemented for a customer, they have two choices for making the payments. One is to outsource their check print and direct deposits to a third party vendor like ADP or Ceredian and the other is to build in-house configurations for these ACH and Check Printing.

The check print configuration needs a custom business form layout which can be generated using XSL. There is another option to create a business form layout using BIRT (Business Intelligence Reporting Tool). But this BIRT based custom business form layout was not allowed to be used for chekc print configuration until WD 23.

I will be using this new feature soon and will share my thoughts on that.

If you want to know how to do a complete check print configuration, we will cover that in our coming posts. Untill then have a nice one.

Basics : PGP Encryption

The use of encryption dates back to the days of Julius Caesar :) When he use to sent messages to his generals, he did not trust the messengers. So, he replaced every A in his message with D, ever B with E and so on (which is basically shift by 3 encoding). Here 'Shift by 3' is the key to understand his messsage.

you must be wondering, why are you telling all these history lessons to a  workday consultant like me?

Sorry if I bored you with that stuff. What I really wanted to do is to emphasize the importance of encryption while sending messages out of our network. In ERPs like Workday where we deal with very sensitive HR information, organizations take this aspect very seriously. 

Workday provides us PGP encryption facility for all the file exchanges we do with other systems. PGP basically stands for Pretty Good Privacy (shocked ? Even I was :)) The general recommendation is to use PGP encryption for all the file exchanges outside of the oorganization network. But as long as you are using SFTP which is already secure, PGP becomes optional.

Integration consultants are often confused whether they need to create a PGP key or ask the vendor to create one for them. The simple thumb rule to this is:

* For all the Outbound integrations to down stream systems, the target system needs to create a key pair and give you the public key (usually a text file). You create the public PGP key and use to to encrypt the outbound files. Give a vendor specific name, dates for validity of the certificate and copy the public key to the Certificate section and hit ok.

Workday Task : Create PGP Key

* In case of inbound files coming into workday, you need to create a PGP key pair and share the public key with your vendor. In this case you just need to give name and date. Once you hit ok, you should be able to see the public key which you can send to the vendor as a text file.

Workday Task: Create PGP Private Key Pair

*** Workday doesn't allow you to view the private key and so you cannot decrypt any vendor files outside workday.

*** I hate to say this, but you cannot migrate the PGP Private Key Pairs, Every time you move your integration to a new tenant, you create a new pair and handover the new key to your vendor. As far as production is concerned, this should not cause a problem as that will be a copy over of GOLD tenant.

If you ask me how I dealt with this, we started using PGP encrypted file starting SIT and so we had to create a fresh key only twice. Try to explain this to your business and vendor as this might take time on the vendor side depending on their approval chain.

Thanks for reading the post. As always, please leave your valuable comments/feedback below. Have a great one.

  

Tip: 'Use Temp File' check box in file delivery

Whenever I configure a delivery service for a integration, there is a check box named 'Use Temp File'. I always wonder what this little check box can do. It did not really make any difference to my file that is delivered on the target server. After digging a little deeper, I understood how critical this check box can be in some situations.

We usually configure sequence generator to generate specific file names to the integration output files. The integration takes some time to write thea file to the target server depending upon the size of the data. In case there is a down stream interface on the target side waiting to consume the file (with a specified name), there is a chance that it might get a incomplete file. To avoid this situation, when the temp file option is enabled, the delivery service gives a random temporary name to the file and re-name it to the correct file name once the file is 100% loaded in the target.

*** Integration consultants must make sure if the user account that we are useing to the load the file has the permissions to re-name the file on the secure file server.

Thanks again for reading my post. I hope it was helpful. Please leave your comments/suggestions below. 

Basics : Web Services

Web Service simply means a service available over a network (internet) typically delivered over HTTP (Hyper Text Transfer Protocol). Web Service is the basic building block for integrations in cloud based ERPs like Workday or Salesforce. You either want to get information out of the system or put into the system, webservices are used. Workday provides many SOAP based web services put into various categories like Human Resources, Payroll, Staffing etc. It also provides a handful od REST based web services. These webservices are coded and maintained by workday and the full documentation is found on the workday community (https://community.workday.com/api)

Below are some of the characteristic features of a web service:

* Is available over the internet/Private network

* Uses Standard XML messaging

* Not tied to any specific platform or programming language

* Self describing via XML grammar

* Is discoverable via simple find mechanism

If you ask me why Web Services? I'll try to be crisp with this:

* Expose existing function on to the network

* Interoperability

* Standardized Protocol

* Low Cost of Comminication

Wondering what is all this SOAP, REST, Web Service, HTTP ?????

Enough of all high level words, let us talk in a language that all of us can understand :)

Consider a leagacy recruting system where you hire candidates and you wish to interface it to Workday HCM using web services. The legacy recruting system is suppose built with visual basic and doesn't know how to interect with your new HR system. Now you pass on the workday web service to the recruting system which basically is a XML document that can be communicated over HTTP. 

* The recruting system bundles all the required information of the new hire into a SOAP message  

* The SOAP message is sent to the web service (Workday API) as a body of HTTP request

* The web service unpacks and converts it into a command that is understood and processed by workday. A response message is also generated with details od the new hire.

* The web service packages the response into another SOAP message which is sent back to the recruting system as a response to the HTTP request

I wish this post was helpful. Feel free to drop your valuable comments below.  I will come up with more content soon. Untill then Cheers and Good Bye.

The First Post

After working on workday implementations for quite sometime, I have decided to start a blog where I can share my experiences with the product. My posts might be more developer inclined as that is my strong suit :)