Opening Cat & Ecatt in Production for Winshuttle

[Former Member]

Hi Gurus,

   We have recently upgraded our ECC system with EHP 5. Currently we are facing an issue with one of our third party tool "Winshuttle" [Non Batch scripts, we use them for park/post docs] to run its script as it requires the following authorization

S_DEVELOP DEVCLASS= ;OBJTYPE=SCAT;OBJNAME=*,P_GROUP= ;ACTVT=16

S_DEVELOP DEVCLASS= ;OBJTYPE=ECSC;OBJNAME=*,P_GROUP= ;ACTVT=16]

also  the client  should be open "CAT & ECATT ALLOWED"

(OR)

Implement one of their Transaction Function Module's and upgrade the version of their software.

The TFM has not been certified by SAP yet. and i am kind of nervous to have the client open for cat & ecatt. I can add the develop access with OBJTYPE - ECSC & SCAT to the winshuttle RFC role so that i can minimize the users who have this authorization. I can further restrict the type of file that could be run by OBJNAME.

I would like to know, would i be opening pandora's box if we have CAT & ECATT ALLOWED in Prod Systems ?

Any thoughts, suggestion are much appreciated..

[Former Member]

Hi Jegadesh,

Looks like you dont have any other option to open Ecatt until TFM is certified by SAP. Check with Winshuttle team how long it will take.

Check if you have any ecatts in the production system apart from winshuttle's. Try restricting with OBJNAME. Users can only execute the ones that are present as you are restricting to execute access and not develop access.

You can verify the roles and production assignments to check who has access to Ecatt. Its a good practice to not have this access in any of the production roles. If you have, you can move it to the temporary roles or create seperate ecatt roles or assign it to a firefighter role (Best option if you have FireFighter Implemented). So that you can monitor the assignments. You can always check the Ecatt logs regularly.

If you take the above necessary precautions and actions, opening Ecatt in production should not pose a problem.

Regards,

Ajesh.

[Former Member]

Hello!.

Executing scripts in PRD system with a tool that isn't supported by SAP is definitely wrong. You shouldn't execute scripts in production system. This could be right when you're doing a initial data load, but once your system is productive, you shouldn't modify it with a external tool, executing scripts for example.

Check official documentation here:

http://help.sap.com/saphelp_nw70ehp2/helpdata/en/49/38ddc2c657200be10000000a42189c/frameset.htm

"Since eCATT tests frequently make database changes, it is not advisable to allow them to be run in production clients."

Cheers,

Diego.

[Former Member]

Hi Ajesh/Diego,

We finally decided to go with the upgrade since security posed a significant threat. I should say i am a lot relieved now . thank you so much for your inputs..

Cheers

JK

[Former Member]

Just to add here, regarding restricting usage from SAPGUI.

Interestingly, even with eCATT and CATT allowed for client under SCC4, still one could block transactions for eCATT and CATT in SAPGUI.

As their tcodes (SECATT and SCAT) were restricted by not provisioning them under S_TCODE authorization object, for the users role in PFCG.

So that eCATT and CATT cannot be used as transactions from SAPGUI.

The system displayed below error messages in SAPGUI on trying these tcodes.

You are not authorized to use transaction SECATT
Message no. S#077

You are not authorized to use transaction SCAT

Message no. S#077

Regards

GS

[Former Member]

This is a client side check of the tcode "equivalent" to the RFC being called. Typically the user can influence this and it is only a check which might not be the correct tcode returned before the processing is started via RFC.

Better than nothing... but much like S_TCODE itself it is blunt and the user must be authorized for the subsequent call, so they could also call the RFC without the S_TCODE check from their client if they wanted to.

A better option in my opinion is transactions such as MASS to use BOR objects to create processing scenarios within SAP or even better is an ABAP application for mass changes (many applications offer this, but often they are not known). Excel data uploaded into SAP tables via the SAPGui is a clumsy solution which should only be resorted to if there are no APIs, and even then the (B)APIs should not require user side scripting or prerequisite update.

As an "acid test" you can use report RSUSR002 for object S_RFC sarching for RFC_NAME = SDTX (function mode rfc_read_table). It is a sure sign that the application authorization concept is being bypassed and you have little chance to remove it again.

Cheers,

Julius

[former_member184158]

I had the same problem,

and I had this message

You are not allowed to execute in -- client ...

1. Start transaction SCC4.You will see a list of all of the clients that have been set up in the system.
2. Choose Maintain, and acknowledge the warning that the table is cross-client.
3. Double-click the client in which you want to allow CATT or eCATT.Depending on the release in which you are working, you will see one of two screens.

just enable ecatt to run it.

[Former Member]

Pretty stupid thing to do in a productive system though.

Cheers,

Julius

[former_member184158]

you are right,

I did not think about a productive system .

thank you .

[david_flad3]

There is at least one use case in a productive environment where the solution (so far) was to develop an ECATT script to handle the work.  This is related to credit card processing -- VCC1 as I recall.

Interactively, if there's an issue with a card authroization and it prevents processing a delivery or an order, the SAPGUI activity requires a search, returns a list of transactions, and then you have to select all, to tag the entries for release for a re-authorization, and then execute the release.

This is great if you only have a few transactions a day and not a large volume of orders/deliveries

generated via an external WebStore, or contain prodcuts that have a lead time beyond the credit card authorization horizon.  of course, it also means someone has to execute this process manually via SAPGUI.

In our case, we want these re-authorization attempts to be automated -- as a result it was an ECATT script in production, as we could determine no other means in the standard system to search, select all, and release.

So -- while SAP cautions against this capability in production, there are some cases where you want to use the standard system-provided transactions, but in a way that SAP didn't account for.  I am pretty certain there are other use cases, but this is the one we've had since 1998.

---- If anyone else has seen the same problem and has a different solution, we're all ears! ---