If you had documentation that BPS is unusable, has very limited functionality and it functionality could be replaced in 2 working days would you pay for additional software?
Of course, if that was going to spare our time for extra deployment of an EAR file every time. Process Integrator is set up once and can be updated easily through DAR installation that we are already preparing for the Webtop client. If you accumulate all the extra effort required for all the involved teams, it might be equivalent.
@PanfilovAB, trust me, it happens. Don't make the mistake of thinking that because you wouldn't do it, others would also not do it. I wish you were correct, however, my experience has taught me otherwise. I don't want to go on record with any specific cases but I see consultants called in to do things that our staff already clearly understands how to do. In fact, we have a consultant coming in to build a production system later this year, and for a very well documented process (from another vendor). Often times it is part of some sort of agreement that is negotiated at the time of procurement, for either the product or a support contract, and management feels like if they don't use it they're throwing away money. I'm just speculating but I suspect it is because they have deadlines for projects and they don't want to take the chance that the on-site team will have trouble meeting the deadline so they include the consultant as a failsafe, then always end up using the failsafe even when they don't need it.
Julien Fontaine, old school is putting it mildly. It's all PDFs. You can't imagine how hard that is to manage until you are the one who has to use it. It might be a convenient method of providing documentation for EMC but it is horribly inconvenient for the customers. Personally, I think if anyone is going to be inconvenienced it should always be EMC in favor or making things easier for the customer. As if having to cross reference multiple PDFs in order to install and manage one product wasn't bad enough, those PDFs are almost always just minor edits from the previous versions, hardly ever platform or architecture specific, and full of errors and omissions that can literally have you struggling for days only to find that you weren't doing anything wrong, it was just the documentation that was wrong. If I were EMC, before I started work on any more features I'd fix the documentation for the existing product, and I don't mean submitting a bunch of DOC FIX SRs to correct the existing PDFs.
It needs to be rebuilt from the ground up, all online, all of it easily accessible in one place, and constantly updated and corrected. Though, I'd still like a wiki, official or not. I disagree with Alvaro de Andres, wikis work great for documentation in the open source world, but usually only with FLOSS, the problem is with open source software that is really just commercial software using the words "open source" for marketing appeal. It can work with commercial software too, but that requires the company to be extraordinary in the relationship they have with their customers, and that usually isn't the case.
If there was good documentation... most likely goverments/public sector would pay support/extra services (either EMC or partners or freelancers) just to have someone else to blame if something goes wrong (I know customers that question why they pay support, and customers that don't pay support anymore because they find support useless ) but I think that's a different discussion out of the topic of this thread.
Alvaro de Andres, my personal experiences can attest to this. It is more about CYA. No one wants to be the last line of support when things go bad. I can usually fix just about any problem I've had, with few exceptions, before I even get to a support representative that even completely understands the issue. In those cases where I do need to work with support, they usually just do the same things I've done, but at some point they pull out some undocumented information that, had I had, I would not have wasted several days on the phone talking to them. This was why I wanted a wiki, the first person to discover this information could then update the wiki to indicate that if you have problem X then use solution Y, noting that it is a verified solution that was used to resolve their specific SR.
I'd like to ask about Java support changes for 7.1. Can you list everything that has changed in regards to Java?
For example, I'd really like to see all of the Documentum process that use Java to use the system Java and not an included JDK. One important advantage of this would be to make it much easier for us to support IT security mandated updates to Java without the need and paperwork involved for obtaining waivers. I have learned through various sources that replacing the included JDK and symlinking (Linux) to your system installed Java usually works fine anyway so why isn't this the way it is done out-of-the-box? Just use $JAVA_HOME and require that a JDK be installed. I can understand limiting the version of the JDK to the most recent stable major version but anything more specific than that won't work for us. If incompatibilities are introduced they should be handled with patches to Documentum and not by requiring a specific version of Java.
I'd like to ask about kerberos (single domain, single forest) multi-docbase support within Webtop. In the past we had trouble configuring webtop for Kerberos authentication for more than one docbase. The user was required to authenticate to subsequent dobases after the initial selection on the docbase selection page. However, we need to have multiple docbases open within the same Webtop instance, to be able to search across these multiple docbases but to never have to type a username and password. The inability to do this is what tanked our previous efforts at upgrading since we had planned on doing a complete architectural overhaul in the process. If 7.1 can support this it would go a long way toward convincing management that the time to go to 7.1 is now.
Don't make the mistake of thinking that because you wouldn't do it, others would also not do it. I wish you were correct, however, my experience has taught me otherwise. ...
Mark, all you had written is, actually, means that your customer either doesn't trust you (your team) or does not think you are qualified enough (I don't want to put doubt on your skills, it's just about how I read that you had written). But I'm talking about another things. Let's give a few examples.
10 of 10 customers face problems with LDAP (though kerberos is more painful) setup, the problems are really different, some of them are:
but all LDAP related problems have the only one root cause - LDAP integration is not properly documented, so, if customer has a strong desire to use LDAP as user source customer need to hire someone (PS, partner, employee, freelancer, etc).
Performance and troubleshooting activities have the same problem: no documentation, no best practices, want to solve problem - hire someone.
Patrick Walsh wrote:
Anonymous SSL mode secures the communication between the DFC client and the Content Server. The new SSL mode also establishes the identity of the Content Server. As you pointed out earlier, this secures the system from malicious internal masquerade attacks that try to spoof the identity of the Content Server.
Yesterday we discussed incompatibilities introduced with Certificate-based SSL:
And that is a real issue, for example: how can we copy some data between old CS and 7.1 with Certificate-based SSL without switching it to anonymous SSL? And I can't understand what was the problem to implement new SSL feature in clearer way? For example:
dfc.security.trusted_cert_alias=cert_alias1that will cause DFC to require server authentication for specific docbase