It happens
that there are systems with identical customizing (fed from the same DEV system
automatically) that are used to hold data of different employees.
Whatever reason
there might be to do so I think it is somewhat crazy, but it happens.
Prerequisites:
First of
all we need to identify what travel expense for an employee are:
1)
Transparent
table PTRV_HEAD (subkey pernr reinr)
2)
Transparent
table PTRV_PERIO (subkey pernr reinr)
3)
Cluster
TE in table PCL1 (srtfd pernr(8) concatenated with reinr(10))
In this few
thoughts I ignore the versioning of the travel expenses because I want to take
all versions with me in the new system.
move the
travel expenses from one system to the other, without having an RFC from one
system to the other.
write the
data to a Transport request (pro: one program only. Con: depending on the
system it might be quite hard to write data to a Transport request)
Alternatives
could have been to create an RFC and use it to transfer the data (provide
Unicode is the same and releases are the same) (cons: requires to open ports in
a firewall and requires 2 programs to be written) or to download the data to a
file (cons: requires 2 programs and is quite error prone)
The program
is quite simple it uses a simple local class to write data to a transport
request.
The
selection part of the Travel expenses data is really trivial.
Here it is:
Z_TRV_2_CR
One thing
that is worth mentioning is that in order to write the TABU K into the
transport request for a cluster table, it is not sufficient to cast the table
line to X and to write the first N xchar to the key field where N is the key
length from the DDIC meta-header.
You need to
put a star in the seqnr field to that all cluster lines of the same srtfd key
Actually
transferring only the first line would cause corrupt clusters, but the nice
thing is that there is a check that does not allow you to write to a transport
request a cluster table with a fully specified key. I really wonder about this.
I would have expected to have corrupt clusters after the transport.
On a dev
system it works fine. On a production system not. Depending on the
configuration.
I had once
written on a production system to a transport request and it worked just fine
so i was confident. But i was too much confident. And it was a mistake. Maybe it was a CUST request that worked, but
this time it was a SYST request, and the TR_* functions do check whether the
system is closed or not. So all the work done is useless.
Shall we stop
in front of these obstacles? We could ask sysops to temporarily allow us to do
it late in the evening when no one is working. But they are not very
collaborative ;-) And they are right. So you have to remember that you are
superman… just kidding, but there was no time to make a RFC (again for the collaborative
sysops it takes a week) or to put a program on the destination system (guess
why i cannot :-) )
So I
started debugging and found the include LSTR9U05
. It is very interesting.
The
TR_SYS_PARAMS are stored in a context (SE33). When one logs on (I suppose or
when the system starts) a generated function is called that calls
TR_SYS_PARAMS_CONTEXT_MODULE. TR_SYS_PARAMS_CONTEXT_MODULE reads the T000 and a
special TADIR line extracting the sysparams and putting them into the context.
Then when the TR_SYS_PARAMS function is called the context is read.
Let’s recap
where each parameter is stored:
systemname = ls_tadir-srcsystem. (PGMID = HEAD OBJECT = SYST
systemedit = ls_tadir-edtflag.
systemtype = lv_system_type. (from the
parameter 'transport/systemtype')
CALL 'C_SAPGPARAM' ID 'NAME'
FIELD 'transport/systemtype'
ID 'VALUE' FIELD
lv_system_type.
system_client_edit =
ls_t000-cccoractiv.
sys_cliinddep_edit =
ls_t000-ccnocliind.
system_client_role =
ls_t000-cccategory.
Now there
are several hacks possible to bypass this check: Change T000 and TADIR (key
HEAD SYST) (this is the mysterious place where it is written whether a system
can be modified or not!!! I was looking for it since a long time). Or simply
hack the TR_SYS_PARAMS in order to return the wanted parameters.
I choose
the last one. Run a program that overwrites LSTR9U05 with this one LSTR9U05-mod. Then run the program
to write the TRV data to the transport request, and finally I put the LSTR9U05 back to the original.
And voila’
the transport request is full of precious TRV data.
Now
downloading the data and cofiles from R/3 is easy, and importing in the
destination system is also easy.
The Travel
expenses (provided the customizing in the systems is identical) can be
transported from one system to the other, by verbatim copying of three tables.
Transporting these data from one production system to the other however can be
tricky… if you use the procedure i used. A better solution (not really a 50
lines one) could be to extend the HRMD_A message type adding the TRV cluster
and table data… and transfer this data via ALE.
Copyright © 2005 Krapinskij
Verbatim copying and distribution of this entire article are permitted
worldwide, without royalty, in any medium, provided this notice, and the
copyright notice, are preserved.
Last update 13/01/2006
11:32