Receiving Web Services - A Primer


Alert notifications, and the output of some reports and data exports can be delivered by posting to a web service.


Typically you will need to create this web service, or have it created for you, the purpose of this KB is to answer the common questions surrounding creation of that receiving web service.


 


1) How do I need to set up my webservice to receive the data, what arguments/actions do I need to handle?


No arguments or actions really. All the web service delivery is is an HTTP POST of a blob of data to a specific URL, if possible this POST will be done anonymously, see #3 below for more information on authentication.  The blob consists of uncompressed XML, so the basic requirement is a web service method that gets posted to, and then reads the blob into something (a file, a database, etc.) 


Additionally, the sending service will wait for a response, however this response is not evaluated, simply discarded and the connection closed.  Currently the only error condition being trapped on the transmitting side is a connection timeout.


2) Does your development team have any sample code?


Well, yes, but the utility of that sample code would be limited. Two things to consider, technology and processing.


a) Technology. Are they using Java? If not Java, how about C#? If C#, using old style .asmx web services or web api? Or just a web page?


Getting the blob of data is relatively trivial. A Google search should expose how to retrieve XML posted to a URL for any technology.


b) Processing. The real work is how they are going to process that XML for their systems, and will vary greatly between customers. They could setup XML objects that everything automatically maps to, use LINQ xml querys, load it into a DOM, use XPATH, write it to a file that another system grabs, process it a line at a time and do something with it, who knows.


Here is the code we use to test the post. Obviously trivial, simply to test that the data gets there. You would never use anything exactly like this (assumes 2k only for one thing), but it shows the basic grab of the posted data from a context:


public class SimplePost : System.Web.Services.WebService
{
WebMethod
public string PostData()


{ MemoryStream postedData = new MemoryStream(2048); this.Context.Request.InputStream.CopyTo(postedData); postedData.Position = 0; string stringData = new StreamReader(postedData).ReadToEnd(); return "Thanks"; }


}


3) How are the user name and password passed along?


Kind of depends on the web service we are calling. We don't explicitly send an authorization header, but the networking layer we use will negotiate with the credentials if the web service asks for authentication. A web service could require basic, Digest, NTLM, etc. for authentication, up to the implementer. All we do on our code side is setup the request, the actual negotiation is handled at the MS layer, we don't really see it. If a customer isn't seeing Basic Authentication, then their web server service isn't sending an authentication request back to our server. Here is an (old) link describing how things work on our end:


 


If you require additional information, or have a question not covered by this KB, please contact Print Audit Technical Support.

How did we do with this article?