Last month, I ran into an error. You know the type, vague, irritating, and an r_object_id that I didn’t recognize. (Okay, I never "recognize" an id given the complexity, but usually I can figure things out from the first two digits.) The error basically said that the r_object_id "53…" did not exist.
Anyway, a quick look didn’t reveal anything. I determined that it wasn’t derived by dm_sysobject by doing a quick query on the table. I decided to throw the question out to Twitter and see what happened.
Okay fearless #Documentum hackers, what object type begins its r_object_id with a ‘53′?
I got two replies, one from Lee Dallas (@ldallasBMOC) and another from David Matheson (@davidfmatheson).
@piewords #Documentum 53 is dm_literal_expr – if you are asking-you need to run data dictionary publish,clear caches restart app svrs
@piewords #Documentum @ldallasBMOC beat me to it, I would add you can check IDfId for the full list of what’s what in any version of DFC.
So Lee gave me the fix, which had already been executed, but he told me why the restart of the client application worked. (The Data Dictionary runs regularly in our environment, so it had already run). David taught me how to answer the question in the future. I also found another way to make the determination as well. I’m going to share them both now.
The DFC Javadocs
This is where David sent me. The Javadocs are simple enough to navigate. Open up the Javadocs and select IDfId from the left-hand panel. You will see a list of constants. Click on any of them, DM_ACL is first, and it will take you to the definition. It doesn’t give you the value here, but if you click that link for Constant Field Values, you will be taken to a table of values.
We aren’t done as there is one final step that David overlooked. The constants are all base 10 decimals. The two character object type tag is hexadecimal (base 16). So if I convert my 53 from hexadecimal (using this nice little converter), I get 83. When I search the table, I find dm_literal_expr, the very answer that Lee sent me.
If you ever need to reverse the process and work from the table (decimal) to the object type tag, you can use the reverse conversion (available from the same source) to get your hexadecimal value.
The Object Reference Manual
So a day or two later, I was looking something else up in the documentation. I then noticed that the answer was staring me in my face. I was looking in the Object Reference Manual that is part of the core Content Server documentation and there it was, Object type Tag: XX.
So rather than navigating the DFC Javadocs for the answer, I can open that manual and search on Object type tag: 53 and get my answer. It is faster and now I have two options.
Extra Side Notes
A few random lessons/observations came about from this effort, so I wanted to share them.
- It is impossible to learn everything in Documentum, so don’t even try. Just learn where everything is written down. I learned two new places while solving this problem.
- I found all sorts of Documentum documentation online while looking for other items. Not sure if it allowed to be up there, but it has been posted by James Azarja on Scribd. The Object Reference Manual for 6.5 is up there as of this writing.
- Twitter is pretty useful for getting some quick answers. It can be faster than the forums on EDN, though EDN is the perfect place for more detailed Q&A.
- The error in question arose when a Composer project was installed. Only one thing was updated in the project, but everything was version, even with no changes. This may turn into a separate post on best practices around Composer (aside from using Application Builder instead).
I didn’t get to go to the SharePoint conference this year, or any other year for that matter, but that doesn’t mean I wasn’t represented. My company sent three people, including Jed Carr, our SharePoint Solution Lead. After much cajoling, I convinced him to share his thoughts on the conference for everyone to enjoy.
So without further ado…here’s Jed.
SharePoint Conference 2009
Anytime you get a chance to go to Vegas, it usually turns out to be a good time. This trip, although work related, was no different…plus it was free. My company flew me out and put me up for this year’s SharePoint Conference. Overall, I thought Mandalay did a great job of managing the 7000+ attendees, most of which really wanted to be there. Also, to my surprise, I barely managed to miss a session. I thought there would be more down time, but every time a session ended, I usually found another one I didn’t want to miss.
Thanks to the Documentum voters splitting their time between two topics, discussing the recent Gartner MQ for ECM is today’s topic. The voting was an interesting little diversion that I’ll revisit later.
I’m going to talk about the report here. The recent controversy around Gartner is a post for another day.
Staying Out of Trouble
Last year I was threatened (my word) by Gartner for putting a copy of the MQ here. I was also chastised for several other nitpicks. So I will only link to Oracle’s courtesy copy of the 2009 Magic Quadrant for Enterprise Content Management this year to avoid wrath.
One thing to remember is Gartner really doesn’t want you to compare a vendor’s location in the MQ from year to year. That is both well-advised and unrealistic. To be fair, as the measurements and industry change, scores change. Movement isn’t just dependent on vendor action, or inaction.
However, we are human and we like to perform comparisons. I have a copy to perform the comparison for my own interest. The link I had online to last year’s report is no longer valid, so you’ll have to take my Word on it.
So, here is the deal. I’m very busy these days, which is good. It only leaves me so much time to write for the Word. I have multiple ideas for my next post, but I can’t decide because I like them all.
Then I thought, why not ask you?
So here are some ideas. Vote and add your own thoughts below for other topics. The ideas that I place in the poll will be covered…eventually.
If you select “Other”, please leave your idea in the comments. I will post the selected entry by Monday evening.
A long time ago, in blog-years, I wrote a page on Building Documentum Talent. I meant it to be something upon which I could build, but I haven’t. Well today that changes, at least for a day. I’m doing two things. I’ve revised that page some (and cleaned old/non-informative comments off) and I’m going to talk about turning your everyday Documentum resource into an expert in this post.
What Doesn’t Kill You
If you read the title, you may think that torture is involved in the “next” step. You would be right. Over the years, I’ve trained many resources that I’ve identified as having potential, and desire, to become good Documentum developers. That is one of my favorite things about new projects, teaching the joys of ECM and Documentum to young consultants.
Unfortunately, you can only train and prepare Documentum resources so much. You can train them and have them write Documentum applications, but they will NEVER become an expert if that is all they ever do. They may become a senior Documentum developer, but they will not become a Documentum expert. That requires a little more work.
Every ECM project, outside of the simplest proof-of-concept, will encounter some challenges. The next time you hit one that isn’t mission critical to solve yesterday, give it to a Documentum resource. Make them solve it. Make sure that they understand the symptoms and let them at it. Be a resource for them, rarely giving answers, but telling them where to find the information.
A few things to consider first…
You may have missed it, but last week, Jean Marie Pascal posted an interview with me on his blog. It was a fun exercise, though it took a while as our schedules precluded quick email responses (my delay being the longer of the two). JM hung in there with me and the interview was finally completed.
If you have been missing the joy of reading fresh posts by me, then the interview will be a nice read. It covers ECM, Documentum, Open Source and a little about me. Share and Enjoy.
This Little ECM Definition Comment
If you went and read the interview, you may have seen my comment on the definition of ECM. I criticized AIIM’s ECM definition as being tool centric. Bryant Duhon, the Infonomics editor, challenged me on this, saying that Strategy was definitely in the definition. I hadn’t responded previously because I knew this was a response. Well, here it is…
Dear EMC,
Hey there. How are you doing? It was nice running into you at the AIIM Seminar last week. I’ve been trying to tell people that CenterStage is not intended to take SharePoint out as we discussed. People are listening, but only time will tell if it will matter.
I want to talk to you about an issue that I’ve been encountering. I’ve talked to you about this before, but I’m not sure that you were paying attention. I just wanted to mention it again to let you know that this is actually important.
