*Introduction* Approved change requests (CR) initiate the creation of transport requests within our SAP systems. Each change request has a unique identifying number. In order to link change requests and transport requests we have defined a mandatory transport attribute Z_CR where the users have to maintain the change request number. Using the expanded selection screen of transaction SE03 (Option +Find Requests+) we can search for attribute Z_CR and change request numbers. The internal control system at Lindt (LICS) demands that a request must not be imported into the productive system by the owner of the request. Admittedly this is not the most sophisticated transport control yet in the context of Lindt (size and complexity of the SAP system landscape) it makes sense - and it works efficiently. In SAP terminology the importing user is the so-called *Admin *user. But where can we find the Admin user? Neither the +standard +list nor the +detailed +list of the import queue (transaction STMS) reveals the Admin user.
*Exploiting the SAP Standard* Looking under the hood of transaction STMS you will find that the function module behind the import history is *TMS_TM_IMPORT_HISTORY* (alternative: TMS_TU_IMPORT_HISTORY). Having the main functionality at our disposal we just need an appropriate selection screen and then build the ALV list around the collected data. Regarding the selection screen we can resort back to another SAP standard function module: *TRINT_SELECT_REQUESTS* This function module offers us the same selection screen like we have for transaction SE03 (Option +Find Requests+ => report RSWBOSDR) and this is exactly what we want. The user who is already familiar with this standard function can use the same selection screen yet gets a different output (see below). *Utility Class ZCL_REQUEST* Instead of using the standard function modules directly I created the utility class ZCL_REQUEST in order to collect all required data of a selected transport request. Within the CLASS_CONSTRUCTOR of this class I determine the transport configuration using function module *TMS_CI_READ_DOMAINCONFIG*. Here I have made the following assumption (which is correct in case of our system landscape but may be wrong in a different environment): 0.1. The first system of the configuration list is the development system (DEV) 0.2. The last system of the configuration list is the productive system (PRD) At Lindt we have 3-systems landscapes (DEV -> TST -> PRD). Thus, for each selected transport request we will generate three rows in the ALV list, one for each system (DEV, TST, PRD). The data for the ALV list are built from three different sources: * Transport History (fm TMS_TM_IMPORT_HISTORY) * Transport Log (fm TR_READ_GLOBAL_INFO_OF_REQUEST) *The Art of ALV Programming* The three different data sources are reflected by different column colours on the ALV list: 1. Transport Request: light and dark blue 2. Transport History: yellow 3. Transport Log: green In addition, I added three status columns: 0.1. +Status=RC+: LED showing the last return code (0=green, 4=yellow, ELSE=red)0.1. +Status:Admin+: Admin=Owner => EQUAL icon; Admin<>Owner => NOT EQUAL icon0.1. +S=Attribut+: Attribute Z_CR maintained => ATTRIBUTE icon; ELSE empty In case of Admin=Owner the status icon depends on the target system: 0.1. DEV, TST: normal EQUAL icon because here the owner is allowed to release or import his or her request 0.2. PRD: _red_ EQUAL icon because here the owner violated the internal control rules Sorting of the list: 1. Request number 2. Counter for systems (1=DEV; 2=TST; 3=PRD) NOTE: A MUST read for all ALV programmers is the excellent tutorial {code:html}An Easy Reference For ALV Grid Control{code} *The Power of ALV Lists* The initial purpose of this report was to reveal violations of the internal control rule that the owner must not import his transport request himself into the productive system. All we have to do is to define a new +layout +with the following filtering options: 0.1. Status:Admin = red EQUAL icon 0.2. Target System = LP0 (productive system) (optional) And here we have the "bad guys" caught in the act: the SAP user USCHIEFERST imported his own requests into the productive system! *Single ALV List - Multiple Purposes * Going back to the full ALV list you will notice the following: the *Admin *user is empty
- when the request is not yet released on DEV (pseudo-RC = NREL)
- when the request is not yet imported into TST or PRD (pseudo-RC = NIMP)
A request which is released but not yet imported into the PRD system may cause a problem after a system-copy (PRD -> TST) because these changes are lost and need to be re-imported into TST. Thus, we define a new +layout +with the following filtering options:
- Status:Admin = TRANSPORT icon
- Target System = LP0 (productive system)
And now the ALV displays a list of transport requests that we should import prior to the next system-copy.