Auto-forwarding mass maintenance - follow on
Trant, David
David.Trant at andrew.com
Mon Aug 1 16:18:28 EDT 2005
I know my reply is late as I'm catching trying to catch up on the
mailing list -- 493 unread messages to go! We have similar issues as we
are on 4.6C and refresh our development and QA systems from production
every so often, scrambling sensitive data afterward. We ended up
writing a program, code shared below, that directly updates the tables
to disable everyone's automatic forwarding post-refresh. Though this
breaks all the rules, we got a pseudo-blessing from OSS on it. We also
go in and turn off all workflow linkages after each refresh. This
requires anyone in the middle of development or testing to go back in
and turn them on again, but the idea is to reduce the likelihood of a
user getting a work item that did not originate from production.
Personally, I don't like this particular decision, but I can understand
the paranoia leading to it, particularly after enough general tasks had
been sent to all users (another "feature" that has already been
sufficiently berated elsewhere in this forum).
Enjoy,
David
Here's the program to delete all the forwarding entries. I see that I
had left a bunch of notes at the bottom that might be helpful to a
techie with insomnia:
REPORT ZBC_DISABLE_AUTOFORWARDING .
*=======================================================================
* Copyright Andrew Corporation 2003
* Name: ZBC_DISABLE_AUTOFORWARDING.
* Title: Disable Automatic Forwarding of workplace items to external
* e-mail addresses in non-productive systems
* Created: 12/31/2003
*
constants: con_app_version(6) value '1.00'.
*
* Process: This program is used to disable the automatic forwarding
* set up in transaction SO36. It is meant to be run after
* a refresh of a non-productive system from the productive
* system to delete substitution entries for all users. This
* has the effect of disabling automatic forwarding. Note that
* any "legitimate" substitutions will also be deleted. Also
* note that dangling references may remain in other tables, but
* this approach has been blessed by SAP via OSS message
* 0120025231 0000278880 2003.
*
* DB Updating: Yes
* Authority Check: Yes/No
* Sensitive Reporting: No
* Menu Path:
*
*=======================================================================
* C O N F I G U R A T I O N / A S S U M P T I O N S
*=======================================================================
*
* Configuration settings, lookup tables, sequence numbers required...
*
*
*=======================================================================
* R E V I S I O N H I S T O R Y
*=======================================================================
* Release Date Userid
* v01.00 mm/dd/yy userid
* Program creation. Program required because/Program requested by...
* Project/Remedy ....
*
*
*=======================================================================
* T E S T P R O C E D U R E S, D A T A, U T I L I T I E S
*=======================================================================
* AC3 documents....
*
*
*=======================================================================
constants: c_sid(3) type c value 'AC1'. " do not run in production
parameters: p_test as checkbox default 'X'. " test mode -- just count
ranges: r_sosu for sosu-usrno. " used as empty table for select stmt
* check authority -- limit to personnel who perform system refreshes
AUTHORITY-CHECK OBJECT 'S_OC_ROLE'
ID 'OFFADMI' FIELD 'ADMINISTRATOR'.
* do not ever run this program in production
if sy-sysid(3) = c_sid.
write: 'This program cannot be executed in production.'.
exit.
endif.
* ensure program is not accidentally run by defaulting "test" checkbox
* to 'X' and only counting the number of entries that would be deleted
if p_test = 'X'.
select count( * ) from sosu where usrno in r_sosu.
write: 'This program will delete all ',
sy-dbcnt,
' records from table SOSU if "Test Mode" is not checked.'.
else.
* delete all entries from SOSU by using empty table in where clause
refresh r_sosu.
delete from sosu where usrno in r_sosu.
if not sy-subrc = 0.
write: 'Return code = ', sy-subrc.
else.
commit work.
write: 'All ', sy-dbcnt,
' entries have been deleted from table SOSU in system ',
sy-sysid.
endif.
endif.
*NOTE: the remaining code was experimental and is not meant to be part
* of the final program. It remains (commented) to show some of
* the relationships between SOSU, which are simply deleted above,
* and other tables containing the information to which SOSU
* points. The central address management tables in particular
* were troublesome in that the functions SAP uses to determine
* actual data are somewhat complex. There does not seem to be one
* single table, for example, that contains the internet address,
* but rather the algorithm seems to check one table, and if it's
* not there, check another, and so forth. This code, therefore,
* is meant strictly as a step in the right direction, not a
* complete roadmap to the relationships involved. Indeed, this
* code does not currently work as expected. Research was
* suspended upon deciding to simply delete all entries instead of
* attempting to retain "core" users' forwarding information, where
* core users would typically be developers, configuration team
* members, and select power users.
*types: begin of t_sosu, " SAPoffice: Substitute for a user
* usrno like sosu-usrno,
* subno like sosu-subno,
* end of t_sosu,
*
* begin of t_soud, " SAPoffice: user definition
* usrno like soud-sapnam, " note there are other key fields
* sapnam like soud-sapnam,
* end of t_soud,
*
* begin of t_adr6, " SMTP numbers (central address admin.)
* addrnumber like adr6-addrnumber,
* smtp_addr like adr6-smtp_addr,
* end of t_adr6,
*
* begin of t_subs,
* addrnumber like adr6-addrnumber,
* end of t_subs.
*
*data: i_sosu type t_sosu occurs 0, " SAPoffice: Substitute for a user
* wa_sosu type t_sosu,
* i_soud type t_soud occurs 0, " SAPoffice: user definition
* wa_soud type t_soud,
* i_adr6 type t_adr6 occurs 0,"SMTP numbers (central address admin
.
* wa_adr6 type t_adr6,
* i_subs type t_subs occurs 0,
* wa_subs type t_subs.
*
*start-of-selection.
*
** get list of current substitute definitions
* select usrno subno
* from sosu
* into table i_sosu.
* check sy-subrc = 0.
*
** map user numbers to userIDs
* select usrno sapnam
* from soud
* into table i_soud
* for all entries in i_sosu
* where usrno = i_sosu-usrno.
* check sy-subrc = 0.
*
** convert 12 character substitute #'s to 10 character address #'s
* refresh i_subs.
* clear wa_subs.
* loop at i_sosu into wa_sosu.
* wa_subs-addrnumber = wa_sosu-subno.
* append wa_subs to i_subs.
* endloop.
*
** map address numbers to internet addresses
* select addrnumber smtp_addr
* from adr6
* into table i_adr6
* for all entries in i_subs
* where addrnumber = i_subs-addrnumber.
* check sy-subrc = 0.
*
*end-of-selection.
*
** print current list of substitutes
* loop at i_sosu into wa_sosu.
* write: / wa_sosu-usrno.
* loop at i_soud into wa_soud where usrno = wa_sosu-usrno.
* write: wa_soud-sapnam.
* endloop.
* loop at i_adr6 into wa_adr6 where addrnumber = wa_sosu-subno.
* write: wa_adr6-smtp_addr.
-----Original Message-----
From: sap-wug-bounces at mit.edu [mailto:sap-wug-bounces at mit.edu] On Behalf
Of Susan R. Keohan
Sent: Wednesday, June 22, 2005 1:46 PM
To: sap-wug at mit.edu
Subject: Auto-forwarding mass maintenance - follow on
Hello all,
I've googled this topic, and I know it's been discussed ad nauseum, but
I still haven't found the
correct way to mass maintain email addresses for automatic forwarding,
so please excuse me.
First off, R3 4.6c, AND EBP 3.5 (6.20) releases. We are talking about
QA systems which were created
as a result of a copy of Production. All PA0105 records have been
scrambled (zkeohan at ll.mit.edu).
All SU01 email addresses can be scrambled as well.
I know about using So12 to 'reset' the autoforwarding address of
specified users, one by one. I
know about using So36 to maintain autoforwarding addresses of specified
users, one by one. Our
requirement is to be able to scramble all autoforwarding addresses in QA
and TEST systems only. I
do not want to do direct table updates, and BAPI_USER_CHANGE does not
fit the bill.
It seems to me, if I could get the existing autoforwarding addresses
cleared en masse, that I could
write a little program or CATT script to call So36 and reset the
autoforwarding addresses from
there. But So36 will not allow you to reset the autoforwarding address
if one already exists in the
activation period. I could even write my own calls to the functions
that So12 uses, but I know that
would be frowned upon ;).
Surely we are not the only customer with these circumstances ? (Please
tell me I am not alone...)
Any help will be greatly appreciated.
Thanks, and happy WF-ing,
Sue
--
Susan R. Keohan
SAP Workflow Developer
MIT Lincoln Laboratory
244 Wood Street
LI-200
Lexington, MA. 02420
781-981-3561
keohan at ll.mit.edu
_______________________________________________
SAP-WUG mailing list
SAP-WUG at mit.edu
http://mailman.mit.edu/mailman/listinfo/sap-wug
------------------------------------------------------------------------------------------------
This message is for the designated recipient only and may
contain privileged, proprietary, or otherwise private information.
If you have received it in error, please notify the sender
immediately and delete the original. Any unauthorized use of
this email is prohibited.
------------------------------------------------------------------------------------------------
[mf2]
More information about the SAP-WUG
mailing list