Once in a while I see people using code to directly access the MCMS database. Today I found a blog from Chester who wrote a module to do this.
Unfortunatelly direct access to the MCMS database without using the MCMS publishing API breaks the Microsoft Support Boundaries for MCMS.
With other words: if you are not interested in using Microsoft Support: go ahead and use this module!
To address question like the one from Steve below:
It might sounds stupid that modules which only read the database are also affected by this statement but the reason is simple: whenever a custom module accesses the database directly it can potentially create database inconsistancies. Microsoft will not analyze the custom module to check if there is harmful code or not. Even if Microsoft would analyze the code - who would know if a previous version was different and already caused inconsistancies? So if such code is included the solution is no longer supported.
Hope this makes more sense now.
Btw: this also includes database access using un-documented API functions.
Thanks for pointing out this to me...
So querying the CMS database directly breaks the support boundaries? That is stupid.
Plus realisticly, how would MSFT know? I can roll the SQL logs as part of "normal" maintenance. How would a query break CMS anyway?
For me, we have to access directly to the database beacause the CMS API is not as complete as it should be ...
So the good question is "When will MS fill all holes ?"
We haven't seen a service pack for a while. Stefan, does MS ear us ? :)
One of the standard requirements from customers is to extend workflow. The two main workflow requirements are: Sending emails on certain actions (submission), and three stage workflow (author - 1st level editor - 2nd level editor)
Our first attempt to do this was to create to follow the idea that querying the CMS database would invalidate support, so we setup a small database with lists of users and groups who were 1st level, 2nd level etc.
The first comment from the client was, this is a nightmare to maintain. It's really important to be able to access the groups in CMS, else integrated enhanced workflows can't be built.
Is it possible to get a SP or something to get this functionality, and it supported?
SP2 is in the works but it will not provide such features. The recommended way to access user information is to bind one dedicated AD/NT group to every rights group. Then add AD/NT users to this rights group. This allows to query the group membership using normal ADSI and there would be no need to access the groups.
Sounds good ... <BR><BR>Glad to see changelog quickly :p <BR><BR>Emmanuel
The problem with this is the exact reason why customers buy CMS from us. As they add new channels, they create new groups with sets of authors and administrators for those channels. What there complaint is they don't want to set these up on two systems, all they want is to add the group through Site Manager, and the workflow picks up the change.
With our clients, which bearucratic in natures, there is a need to have seperate groups for seperate areas of the site. We need to provide integrated workflow.
Stefan, I've three questions related with Microsoft Support,
1. If the database is consistence
2. No custom module is used in the solution which directly handles the MCMS database
Then are we inside the Microsoft Support boundaries?
If the answer is yes then (have two questions related with the answer yes),
Somehow (without using any custom module which directly handles MCMS database) if the MCMS database becomes inconsistence
Then can't we get the Support of Microsoft?
If we use some other tool which directly handles MCMS database and if the database is consistence then are we in the safe side?
What Stefan suggested is a workaround : it means that a solution was find to bypass the problem but this solution is far from being the most _elegant_. I faced the same problem when I wanted to extend the CMS workflow.
"Workflow extension" is sold by everyone (specialy the marketting team) but after the fact, it seems that nobody succeed on extending the workflow due to a lack of the API :)
But this is another discussion :)
Emmanuel, your comment is not correct. We have a couple of customers which successfully implemented their own custom workflow extension. In addition there are 3rd party workflow extensions which nicely integrate with MCMS like K2 and TeamPlate.
I'm not talking about solution like Teamplate or K2 because they have their own workflow engine.
Depending of your workflow customization, we can not implement this through the API.
I'm ok that sending an email alert, keeping 3 workflow levels can be easily done but what about a more complex workflow ? We have to use Saul's tip or I missed the magic trick :)
Chester has again posted&nbsp;some "tricks" on his blog about how to enhance MCMS using unsupported methods.And...
Glen has written an article that outlines how to manipulate the MCMS database using unsupported methods...