David,
That's a GREAT question. I don't know that I could answer that for IDM 8, as most of my experience is 7.x based, but I'm happy to start the conversation.
First off, it depends on what your role in the IDM project is. Are you a consultant or an "in-house" developer? If you're a consultant, I'd start talking to the clients about current standards for other SAP modules. Ask if they have any existing guidelines for development in general, and SAP in particular. Even though IDM really isn't like other modules, it's a good start, as is any templates that currently exist.
As far as particular best practices, I can think of a few to start with, I'm sure others will kick in as well:
- Do not start any custom IDM objects (attributes, entry types, scripts, packages) with "MX" or "SAP", so they don't get overwritten should SAP have the same ideas and use those names.
- For custom objects do use a prefix, "Z", "CUS", "IDM" are some examples I've seen.
- Also when referring to custom objects you can use prefixes that reflect the project name or company are good. Also sometimes using specific names that reflect sources / destinations like AD, MSSQL, CRM, FEED, etc are good, and sometimes combined with the prefixes in the previous example.
- Do document all code. Some day you will be on an other project or sitting in the corner office (maybe both!) and someone will come asking a question because the only comments are your name. Having some extra documentation about what is happening here, formatting examples, function details, etc. can only help.
- Do document passes, jobs, and tasks. Whether you use the built in documentation tab, a Word DOC, One Note, or some other system, just make sure it is updated often and available to who ever needs it (other developers, testers, compliance folks, whomever, see above) also make sure it is backed up (see next point)
- Do backup often and in multiple ways. Make sure regular backups are occurring in your environments, export code and place in a repository like TFS or SVN. If you're writing queries, save those too, you never know when you can reuse things.
- Do not make changes to any stored procedure or to the database directly. Very bad things can happen from here unless you are doing it on behalf of SAP. There are differing opinions about using said stored procedures. Personally I'm OK with it if properly tested (and documenting how you are using them, but there are those who feel differently..
- For 7.x systems, do minimize the number of developers in MMC at the same time, and make sure that people are not working on the same job at the same time. This can also cause bad things. It's one of the key things that excites me about IDM 8.0.
- Do read all of the documentation provided by SAP. There's probably a ton of things in those documents that could be added here when considering best practices.
- Do attend training if at all possible and keep up with it. Even though there is no SAP certification for IDM, it's still a good idea. Also many instructors have worked on multiple IDM projects, or at least participated in testing and work with the developers. They will probably have some good experience to pass on to you.
- Do read and contribute to the IDM forum here. There are a LOT of really smart people on this forum with years (some with more than 10) on the product. A review of the content here will probably help any questions you might have. Odds are, you're not the first to wonder how to do something, or what particular best practices might be helpful.
This is just off the top of my head. I'm looking forward to seeing what others think. If it makes sense, maybe we should compile the answers into a document, or at least forward to the developers so that they can create / add.and publish.
Anyone else???
Matt
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.