A Better PSI

[Bryant Likes]

I would like to start a discussion on how the PSI could be improved. As it
now stands here are the primary issues I have with it.

1) Web service interface only.

Now I understand that web services are a good thing, but you should offer a
way to integrate that doesn't require a web service. Or at least offer a
different protocol other than HTTP since that is so slow. If I'm interacting
with the PSI on the same machine there should be some in-proc mode that will
let me interact directly instead of having to pass everything over the
network.

2) Datasets are big and bulky.

It seems like the PSI was built to support PWA and Project client and then
shipped as is for the rest of us to use. While datasets that contain
everything including the kitchen sink might be required to load a project in
PWA and project client, I don't need everything. Most of the time I just want
to update a single field in a single task. In order to do that I have to:

a. Download the project dataset. While I need only one task this gives me
the entire project which many times can be as big as 14 MB of XML data which
all has to be sent over HTTP.

b. Apply my change to the dataset and get the changes. This makes my second
call somewhat easier since I have a small amount of data to pass back.

c. In order to make my update I have to deal with the queue which is a great
feature when it comes to scalability and such but is a real pita when you
have to manage jobs in order to do a simple update which is my next issue.

3) Don't force me to deal directly with the Queue.

While I like the queue system, here is where it gets really fun. In order to
make my change I have to check out the project, submit my changes, save the
project, publish the project, and check the project back in. The process can
fail at any point during these steps and I have to code to handle all of them.

The other fun part of this process is that many times when I update the
task, project decides to not actually update it and to do something else
instead. So as part of the process I actually have to download the entire
project again and check if my changes actually went through. If not I have to
resubmit my changes and manage all the queue jobs again.

I would much prefer for the PSI to be a real webservice where I could get a
specific task and make changes to that task without having to write my own
queue to manage the project server queue. Even though Project uses a queue,
that should be somewhat transparent to the developer who is trying to
integrate with project. Why not expose the API as async web services?

4) Incomplete Documentation

The last issue for me is the documentation. While I know it is still a
fairly new product so probably not a ton of people working with it, it seems
like a lot of the things I do should have already been done by someone else.
However, most of the time I'm stuck with poking around in Reflector to see
what project server is actually doing and/or just writing lots of tests to
try things out and see what happens.

Not only are a lot of the processes not clearly documented, but the fields
themselves are not documented. Take the gigantic dataset that comes back from
get project. What the heck are all these things you've sending back to me?
What do these fields do? What happens if I change them? Etc, etc, etc. I
think this is another drawback to the dataset approach.

Ok so those are my gripes. Am I way off? Is there something I'm missing? Let
me know.

BTW - For my current project I'm actually working on a nice RESTful
interface that sits on top of the Project Server databases so that I can get
a single task if I want which out the entire project dataset download.
However, I'm still stuck if I want to make a change since I have to get the
dataset in order to change anything. But I will be writing an async WCF
service to wrap all the functionality that I wish I had out of the box.

Thanks!

 

[Rod Gill]

If you are working on the same box, VBA is still a great solution.
Development times are typically a tenth or less, speed is as fast or faster.
One statement to save, one to publish and one to close the project, you let
Project professional do all the error handling!

I agree PSI is way too complex. A typical power user of Project in a Project
Office is never going to learn C# and the PSI. I too wish PSI could be used
easily from Excel VBA say.

--

Rod Gill
Microsoft MVP for Project

Author of the only book on Project VBA, see:
http://www.projectvbabook.com

 

[Bryant Likes]

Thanks for your reply Rod.

I haven't looked at VBA much yet. We have implemented a Proof-of-Concept
using the new Project Client add-in from Visual Studio 2008 which works
pretty well. However, we really need to interact with the server side of
things since we are doing project updates using an Excel Add-in.

Thanks again!

 

[Andrew Jacks]

Bryant

I'm not sure that I fully agree with your issues.

1) Web Services Only

Yep, this is a drawback. However with now WCF out I hope that release of
Project Server allows us to communicate through other methods.

2) Datasets are big and buky

But compared to what. I like the fact that Datasets are used. They make life
easier for me when developing code against the PSI. I'm not sure that it is
practical to maintain other methods to hold the Project Server Data (i.e.
objects)

I think the real issue is the amount of data requred to process a particular
task. i.e. If you could just get the task for a project without getting all
the project data then maybe that would be better.

3) The Queue

I think the queue could be handled better. I has caused a number of issues
on Client Sites. But I do not think the concept behind it is good and one
that does not need to be change.

4) Documentation

OK I give in. We do need beter documentation.



I will be interesting to see what Microsoft Employees have to say on the
matter

 

[Bryant Likes]

1) Web Services Only

Yep, this is a drawback. However with now WCF out I hope that release of
Project Server allows us to communicate through other methods.

Right, but that would not be until the next version of Project is released.
The current version only supports HTTP.

2) Datasets are big and buky

But compared to what. I like the fact that Datasets are used. They make life
easier for me when developing code against the PSI. I'm not sure that it is
practical to maintain other methods to hold the Project Server Data (i.e.
objects)

I think the real issue is the amount of data requred to process a particular
task. i.e. If you could just get the task for a project without getting all
the project data then maybe that would be better.

So you agree with me.

I'll live with the datasets if I have to, but they are not granular enough
and because of their design they include the kitchen sink. Just give me the
data that matters, not all the project stuff that I can't change nor make
sense of.

3) The Queue

I think the queue could be handled better. I has caused a number of issues
on Client Sites. But I do not think the concept behind it is good and one
that does not need to be change.

I agree with the concept too. I just think they should put a service in
front of it that handles all the interactions. I shouldn't need to program
against the queue.

4) Documentation

OK I give in. We do need beter documentation.


I will be interesting to see what Microsoft Employees have to say on the
matter

I'm beginning to wonder if they even read these forums. Haven't seen
anything yet since I started reading them.

Anyone from the project team out there? Are my questions too hard? Too easy?
Sore subject?

Thanks for your reply...

 

[Guest]

Hi Bryant,

Compared to PDS I think web services are the greatest thing since sliced bread.
The fact that I can write an extension web service allows me to create custom
methods that return only the data I need. Of course if someone comes up with a
better interface, I’ll be happy to use it.

But to be honest with you I would rather see the current PSI fleshed out a bit
before anyone starts building some other interface. My own wish list would
include a significantly improved calendar interface and the ability to deal
with project baselines.

I am also a big fan of datasets. I think the trick is to create a web service
extension and use it to extract the application specific data you need to use.
Then your application just calls your custom web service method. It works well
for me. The only thing I haven’t been able to figure out is how to return a
typed dataset from my custom web service to my client application. I keep
asking (It feels a lot like banging your head on the desk some times...), but
someday I’ll figure it out.

The queuing service is a pain at times, but the scalability trade off makes it
the right choice. Frankly, I have had to add another application specific
queue in one of my recent efforts. They are hard to beat when all of your
users are required to update their assignments twice per shift.

I have to agree with you when it comes to documentation. I have spent multiple
man weeks figuring out two or three different issues that basically boiled down
to documentation holes. About all you can do is put a question in this group
and hope some responds. If you are pushing the development envelope, this
doesn’t always work…

Bob Segrest