
SAP R/3 repository is a wonderful thing. A vast warehouse of data elements, structures, tables and much more, readily available to one and all. As developers, it is extremely convenient to quickly pick these elements and pull them into our programs as necessity conveys, while our string of thought remains virtually uninterrupted.
Well, not all is sunshine and roses. If you are not careful with the mushrooms you pick you might get a poisoned one. Imagine the common scenario in which you pick a customer convenient data element. It looks OK and well suited for your requirements. So you happily include it in your data declarations and pay no more attention to it. What you just failed to realize is that this small data element “belongs” to one of your colleague’s applications and, conceptually, it should never be referred in your application, simply because they are two completely independent and unrelated applications that now share a poisonous bond: they became interdependent.
Application spaghetti is a common scenario in SAP IT teams and it sometimes evolves into some unwanted-dependencies troublesome situations. For instance:
These issues can be easily avoided through careful package design and package checking all your developments.
As a developer you might find that SAP Package Concept goes beyond being just an object container. Using a combination of structure packages, main packages and development packages interconnected by package interfaces and use accesses, you can safeguard your applications from unwanted object picking.
Here are some basic package concept guidelines:
And now for some golden references to get you started:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
User | Count |
---|---|
3 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 | |
1 |