Microsoft Technical Support For Project Server API (PSI)

[BradleyWard]

I called Microsoft technical support today to open a support incident. The
problem is quite simple. On one specific project, a simple demo program I
wrote shows that the basic ReadProject() call fails. And the only error
message you get back is "Object not set to an instance of an object", which
is occuring inside of Project Server 2007.

His response: He asked me if this was inside one of their sample pieces of
code. I said no. He then said that Microsoft does not support "custom code".

I then said (incredulously) that this was an API. The ENTIRE purpose of an
API is to write code that calls the API. An API has no user interface!.

But he stuck to his guns.

The current state of this support call is that I am asking him to show me
either on a public website or in an official document of some sort where they
publically state that they do not provide any support for developers using
their API.

Has anyone heard anything like this? This is one of the most unbelievable
things I have EVER heard from a software company!

 

[Rod Gill]

Take an analogy: You buy a car, do you expect the car maker to support you
with problems getting backing the car into a garage?

The software problem could be a configuration problem, a corruption in your
project or database or a character wrong with your code. It could also be a
bug in the API call, but you would have to prove it. For example if a
parameter is meant to return Task data ands it returned Resource data, then
providing your call to the API was correct there is a strong case for a bug
in the API, especially if the same result occurred for other people.

I understand your frustration, but they can't test for most problems over a
phone, so if you can do some testing and checking with other projects and
environments (your test instance say) and ideally another Server setup then
you have a case. However, the ReadProject call is one that is working fine
for many people, so I would expect a problem with setup or a corruption in
your system before the API call.

--

Rod Gill
Microsoft MVP for Project

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

 

[BradleyWard]

To use your car analogy, this is more like a customer buys a brand new car
from a car dealer. He then brings the car back to the dealer and says it
won't start, and the dealer says "Sorry, we wont't help you with that.". Sure
the customer may have left the headlights on but for the dealer to say "as a
matter of policy we do not help customers if their car does not start. We
don't even try."... that would be pretty unbelievable!

I would be fine if the support person looked into the problem then saw
something that I did that was not correct and told me I had to fix it. But to
not even take the very first look as a matter of policy? What kind of
software company does that? In my 35 years of professional software
development I've never met one until now!

To be more specific, in this case I am calling the ReadProject() method in
the Project PSI API. That call takes two arguments. The first is the GUID of
the project to be loaded. I am absolutely sure that is correct because I just
pulled that GUID from the response from a previous PSI call. The second
argument is an enumerated value telling it what data store to get the project
from. I am pretty sure I sent a valid value in for that one too because in my
little standalone demo program that is hard coded to
DataStoreEnum.WorkingStore.

The response I get from the API call? "Object not set to an instance of an
object".

The first rule of professional API design and development is that you ALWAYS
assume the calling code is wrong. So if I sent a bogus GUID in I would get
something like "No project found with this GUID". Or if I sent the wrong
value in for the DataStoreEnum, I would get something like "Invalid
DataStoreEnum value.". Not "Object not set to an instance of an object".

Another CRITICAL thing a well designed API must do is to protect its own
internal integrity. Don't let bad data in. Reject it at the outset. This is
particularly important when dealing with a database based application as
restarting the program or rebooting the computer won't fix anything if the
database is allowed to become corrupt. I am perfectly willing to admit that
I probably sent in some bad data somewhere, but even if I did, why was that
not rejected?

But even if this API had perfect validation logic (it does not) and gave
perfectly clear error messages (it does not), it will still fall prey to one
of the only truisms in software development and that is "there's always one
more bug". So I expect this and am perfectly willing to deal with it. And I
have done so with many different software vendors over the years.

But I have never, until today, had a software vendor take the initial stance
before looking at ANYTHING that they will not help. That it is their official
policy to not help you if you are writing code to use their public API. Duh,
what am I missing here?

Personally, the very fact that Project Server 2007 is returning an "Object
not set to an instance of an object" error message at all totally proves that
there is a bug somewhere in the Project Server 2007 application. But of
course this was not evaluated today due to the official policy being that
Microsoft won't support developers using their API.

I am fortunate that one week ago when I opened another tech support call
about how Project Server performance grinds down to almost zero, the call was
welcomed and the engineer jumped right onto the problem. But I don't think
that engineer checked with management first like today's engineer did.

(BTW: This is the 3rd time I have tried to post this, only to have the
microsoft.com website fail and lose the message)

 

[Gary Chefetz]

Brad:

I am not a developer, but in my limited experience, the error often
indicates a failure to connect to the data store. As for your automobile
analogy, I think something like a Manufacturer not covering you for
breakdowns on a car where you chip the engine would be more of an apples to
apples comparison. Microsoft support is for break-fix issues, not
development issues. If you can provide steps to reproduce on multiple
systems, then you've got a support case. Otherwise, MSDN managed newsgroups
are a great place to start. Posting code samples will get you further along
in the process if you want peer-to-peer support here.