This post will finish up post 7 by beefing our client access to the service application with logic to enable/disable the service from central administration without deleting it.
First, lets take a look at DemoApplicationProxy with some new additions – note I added Guid serviceAppID where serviceAppID will eventually return the DemoServiceApplication identifier. (refer to the last post for supporting material)
I also need to add two methods, the first is one here makes the connection between our server and client code bases.
oops: in the image above my "return" is in the wrong place – but you get the idea
A few comments about the above code. Most importantly, its coded to return data only if (at least) one instance of the service application is enabled using SPObjectStatus.Online. This is a fake out. Recall that even without a service instance created we can grab a reference that still allows the service application to work. In our non-WCF, single server mode this simply simulates the on/off capability of the CA management screen. Its not code that will end up in the final solution. In fact, I could not even get the on/off behavior to work properly without this code. I don’t know if its because I lack some information around using instances on a single server, non-WCF service application or something else. So that clarification will need to wait for a future post.
As seen in previous posts, the next image shows how this looks in central administration where SPObjectStatus is controlled. I’ll demo the behavior at the end of this blog post.
The second point related back to post 7 and where I disclose that the DemoServiceInstance really does nothing for us just now – I’ve included it mainly because this will end up a necessary component as we move into a multi-server, WCF based server application.
The next method returns an instance of the service application based on SPServiceContext passed in by the client.
Finally, I refactor the the client code (our page web part) to use the service context and proxy class as follows.
The results of these changes allow the service application to work only when the its properly started.
If stopped, the page appears as follows,
Results on page,
If started,
The page now appears with data,
Now that we’ve added the proxy classes to our application we can see these show up in “Manage Service Applications”
We are now nearing the end of usefulness of this non-WCF demo BUT I have 2 or 3 topics I want to touch on before we shift into using WCF end points.
My proposed agenda for the next three posts are: provisioning a service application database, using REST to call into this service application (a fun one), and finally adding Powershell administrative commands. After that we begin our WCF version of this application with a discussion (and code) regarding load balancing, publishing services out to other farms, and claims based authentication related topics. The last installment of this series will be refactoring the business logic for something more “real” as a final demo.
See you next time – Cheers!