SAP is delivered error free. Well, by design there shouldn't be any errors. Data integrity is one thing they guard. And so should you ! Data integrity is all about taking care of your data. SAP makes sure their tables are filled with proper data, by checking everything before it is allowed into the tables. When e.g. a purchase order is entered for a material number that doesn't exist - the save button on the purchase order application simply won't work.
Take this concept further, using the available tools (locking, database management applications, authorization) and your system will have "proper data" - data integrity is secured.
This issue is about making sure the data for standard SAP applications remains uninfected... And also, making sure the newly build applications will have a secure data integrity. Always remember: the system you are working on is very important for the company - decisions are made and processes are controlled based on the data you are handling. Better make sure you don't disappear in one of the pitfalls of data integrity...
What you should do and not do where data integrity is involved...
- Do Check the 7 sins of Data Integrity
- Don't Blow holes in SAP's data integrity
- Do Value data integrity - it's all the system is about
Data integrity is a very important factor, not just for computer systems. A system which is used to control the processes of a big company (typically an ERP system) should handle it's data integrity with a lot of love and devotion. Imagine a system which performs it's task very well, but every now and then a small hitch presents itself. It should automatically make you wonder how many actual hitches took place. The fact that you noticed this one, does not imply it was the only one around. With a good data integrity it should be quite easy to pin-point what happened, and how many of the same hitches are around. Without data integrity - there's no telling what your ever-so-important system will do next.
Sometimes unavoidable, mostly unnecessary and nearly always present: hard-coding in developments. Sign your name in solid concrete.
Sometimes it's literary printed in a functional specification: select form somewhere for company code "XX34". The report is designed for this company only and there is no expectation of use for other companies. But is that enough reason to actually block all other company codes from using the program ?
SAP protect's it's data by ensuring all data is checked and approved before it is stored. Data integrity is the insurance that the data in your system is correct, which is something that should be protected. What if it's your report that damages the data on your system ? Any ideas on how it should be fixed ? Prevention is the better option here...
I'm sure the biggest background jobs that are running on your live system are important and they get a job done that plays a big part in the system's overall function. Prices need to be (re)calculated, stocks need to be adjusted, an outbound interface on material data needs to be completed. The coding for these - big boys - has been optimized, the performance is tuned and there's is not much more that can be done from a technical viewpoint. Consider using a processing queue.
Your data integrity could be secured - but data integrity issues can still arise: integrity in reporting - when using SELECT SINGLE
Even though data is stored correct and complete - it could still be presented to the end user the wrong way - which results in data integrity problems as well. An error in a report could lead to faulty answers which should be spotted in the testing phase. "Nothing that cannot be fixed". However:
A method to visualize the life of a development (program). If you would like to check what happened to a given (customer) development since it was created, an ABAP report gathers transport details along with the program's size (counting the number of lines). The size is used as a complexity-barometer and it's interesting to see how many changes have been applied, how much time between changes and whether (and how much) the complexity grows (or decreases).
Documentation of technical objects is very important, but not always available, reliable or up to date. The one thing that a developer always has, is the actual coding itself. Whatever "the others" have build before you, any developer will point out things that should be done in a better way. Developments hold a sense of developer personality, which is exactly why developing is what it is. The source scanner can be a helping hand.
The problem with spaghetti coding is that it was build as proper development which turned into spaghetti with time. This article helps recognize the state of a (any) development...
The spaghetti test is a simple and straightforward manner which can help you identify the state of a development quickly. Please be aware that only a few common symptoms are checked (by you), an automated check is also available on your system: the code inspector (version 4.7+). Especially the "visual" checks will tell you more about the development (spaghetti) state:
.. becomes muddy and sticky. The AbapcadabrA authors point of view: when developments are done in limited time (which is always), the quick and dirty approach tends to present itself.
"Worry about the not too important stuff later"- Later is often enough never.
"Don't fix it until it's a problem"- All we seem to be doing is fixing problems.
"The fix was really small, finding out where to put it was very time consuming"- A clear sign of spagetti coding.
Would you like to know how much work is involved to make sure any given (custom) development is overhauled ? An overhaul is a series of development improvements that should bring a development to a quality assured level. Data integrity, performance tuning and the avoidance of hard-coding are the main targets for an overhaul. The exact details of the overhaul can be defined according to the programming conventions on your project. This overview outlines the main subjects that should be covered:
Ensuring the health of an Abap development - is backed by serious tooling. The code inspector is a tool that is available from the Abap editor and it takes a serious look at your coding. I have done several projects where all coding was to be delivered code-inspector-error-free. And the use of compiler directives was not allowed.
Compiler directives can be used to indicate that the error should no longer be listed in the code inspector. It's a way to make problems disappear, by the hand of the developer who chose to add the directive. If the choice is founded - the whole setup works. If the developer just runs through the code inspector errors to put a directive behind them - he/she should leave the errors as-is. A compiler directive that has been put in place incorrectly is a developers sin. Should never happen. Ever.
As of ABAP release 7.0 EhP2: Pragmas or Program Directives can be used to hide errors and warnings from check tools, the Abap compiler syntax check and the extended program check (but not the code inspector - I'm afraid). Pragma's have no effect (affect) on the actual program flow. A pragma is very simlilar to a compiler directive, and pragma's and compiler directives should not be used together. They can be mixed, but it confuses the h.ll out of people. The pragma is the official successor of the compiler directive, which should no longer be used.
The code inspector is an elaborate bit of kit, that can help yoo and your team avoid coding mistakes. I'm assuming you've discovered it's great potential and you have been delivering your own coding code-inspector-error-free for a long time now. Well done ! Would you like to do better ? Add your own checks.
Once the coding issues are resolved, you can check the state of health of your system with "health check reports".
The Health check report targets problems that are not expected to happen. When e.g. the Business defined a document should be in a status "To be approved", "Released" or "Rejected", the report would list documents in a status other than these. If the 3 statuses from this example are expected to cover all documents - other statuses may go unnoticed, causing data integrity which looks very innocent.
Error logging is something that needs to be done throughout the system for every process. Make sure you know about the Business Application Log (BAL).
The BAL is a powerful nearly-end user tool that could be used to place error messages on processes that cannot report the errors immediately, e.g. because the error is in a background process (batch job or Idoc processing). You can use the BAL for your own applications as well - here's how:
Worried about parties stealing code ? Do you want to ensure no-one can touch, run or even see it ? Do you want to show the customer a demo on their own system, without leaving it there all exposed ? Lock your coding with the code locker. And re-instate when you needed, in under 2 seconds.