that leaves two options. One, you give permission to use SE38 to whatever user needs to run the report. Auditing will look very disfavorable upon that option. Or two, you make a script that does what you need, and call it.
Now, in the past, I have simply created my scripts on the OS, and caleld it from within SAP. It was simple, clean and functional. I did it, because it was easier to do, and because I had access to the OS.
But this week, I was posed with a problem of having to delete multiple files from a directory, of a certain date and with a specific syntax. something that I needed a script for. But I have no OS access to the systems. So what do I do ?
Well, I look at the type of OS my SAP is running on, from my system information:
then I create a small ABAP program with the following data
REPORT ZZ_CLEANUP_INTERFACE_FILES_1.
DATA : my_command(255).
DATA: BEGIN OF MYTABL OCCURS 0, " defines output
LINE(255),
END OF MYTABL.
my_command = 'find /usr/sap/interfaces/*zip* -mtime +15 -exec rm {} \; '. " the Linux command
CLEAR MYTABL. REFRESH MYTABL.
CALL 'SYSTEM' ID 'COMMAND' FIELD my_command
ID 'TAB' FIELD MYTABL-*SYS*.
LOOP AT MYTABL. " displays output
write :/ MYTABL-LINE.
ENDLOOP.
Had the system been a windows box, I could simply have typed in a windows command in the my_command field instead.
Do I need to run more than one command, I can just do a new my_command followed by a new SYSTEM call.
Do I need manipulation of the data, I have the output, line for line in MYTABL.
The really huge upside to this strategy is that: It's totally hardware independant (ok, it will only run on a similar OS, but I can move to another server and it will still work), I can limit access to the report via normal SAP authorizations, and I even get reporting, documentation and alerting similar to any SAP report.
I am certainly one happy camper, and might entirely forego the use of OS scripting in the future.
No comments:
Post a Comment