.. can help you understand the ins and outs of transports. This example adresses a method that could help you understand any transport and correction problem. Here's a problem that I came across: we build SapScript forms that represented a letter that needed to go out to the customer. For this letter, a standard text was created and included in the SapScript. The idea behind this is that this standard text can be changed in the production system, without getting in another ABAP SapScript programmer. Standard texts can be maintained with transaction SO10 or R/3 -> Tools -> Word processing -> Standard texts.
When a standard text is created, no transport request is required because standard texts are not added to the transport system by default.
Of course, these texts should be available in other systems as well, which can be done in several ways (like anything in SAP really). First of all, they could be recreated and retyped in the target system, or they could be downloaded and uploaded again (available functionality) or the Transport system could be used. With Transport & Correction, table contents can be transported, so the table contents for out text tables could be transported as well. But of course, there is an object type for texts as well, which I want to use here.
To understand how the transport and correction system works, have a read through the topic above first. System administration on this is available in tables
E070- R/3 command file andE071- Objects of a request or task.
It's table E071 - Objects of a request or task, that can be important here. It is packed with examples of how to do transports for a certain object type. I found type TEXT as object type (which just sounds logical doesn't it ?), and sought for existing transports in E071. Looking at these examples, a new entry can manually be added on any object list and the relevant object name can be populated. Manually or by means of SAP functionality, like RSTXTRAN for longtexts.
These tables are really only used to select the objects that need to be exported. And of course to "lock" the objects that are being changed, so no 2 sources (transport requests) can apply changes to a given object at the same time. The "Objects of a request or task" table does not hold actual "content", just information on which content to select when performing an Export. Once the transport request is released, the Export is done, in which a file with actual object content is composed. When the object identifies a Smartform, the Export file will hold all the information needed to build this Smartform in the receiving system. The same applies to reports, table contents, really anything that SAP can throw at you can be moved in a transport. Think of this a little - cos it's a lot !
So why are these articles about the transport and correction system listed under "Interfacing" ? In fact we are interfacing anything thing that can be created in SAP through SAP's landscape. An interface with which even interfaces (reports or Idocs) can be interfaced. Check out the enormous list of object types that are supported. Each type can be used to wrap up the object, move it to the next system and unwrap it. Interfacing.