Documented / Undocumented API – Why Should I care? – Part 2

Part 2 – What would YOU do?

Lets assume you have developed a nice application – lets say a Web Application that uses a backend database. To allow your users to customize the application you have implemented an API that customers can use to savely program against the application.

Unfortunatelly due to time constraints you did not manage to implement APIs for all possible settings. To address this you are shipping a tool that allows your customers to configure the rest of the settings. With other words: your customer have everything they need to configure all aspects of the application but some things need to be done by hand while others can be scripted.

Now suddenly a 3rd party company shows up and sells an add on to your product that allows to script even the things that cannot be scripted using the API provided by your application. Sounds great, doesn’t it? Someone else took the burden off your shoulders to develop these API calls based on undocumented program internal interfaces! Shouldn’t you be happy?

As you are also providing support for your application from day one on where you shipped the application some customers raised cases for problems which finally were identified as database inconsistancies in the backend database of your application. As the customer ensured you that he never touched the database (which would be unsupported) it is most likely that a glitch in your application causes such inconsistancies. So you are usually not charging your customers for the correction of these database inconsistancies as they seem to be caused by your application.

Suddenly you recognize an increase of service requests with database inconsistancies. In some situations even data loss has happened. And customers experiencing this kind of problems were using the tool from the 3rd party company to script the non-scriptable part of the configuration. Lets darken the picture: lets assume suddenly several hundred of your customers raise service request all caused by database inconsistancies. A significant percentage of your support people are suddenly involved in correcting database inconsistancies – most likely caused by the 3rd party companies add-on to your application.

What would you do in such a situation?

Hopefully you will now understand why Microsoft limits support for MCMS for problems caused by database inconsistancies where 3rd party applications are involved that use undocumented program internal interfaces to modify the MCMS repository content.

Reference

Part 1 – Technical Background
Part 3 – How to identify 3rd party products using undocumented program internal intefaces