Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

How to allow access to BDCP2 table

Former Member
0 Kudos

I have support users who are requesting direct view acess to table BDCP2. This table does not show in the list of tables in TDDAT to find the auth group. I had to view table attributes through SE15 in order to discover that it is an SAP table assigned to &NC&. We do not grant access to that group in production. I know that I can have them either assign it to the SA group (where BDCP table lives) or have them create a custom transaction to use to view it.

My concern, or question, is this: since SAP delivered it assigned to &NC&, were they assuming it would not be viewed directly? We are a brand new SAP shop and our developers and users are just learning. They are not happy when I tell them they cannot have SE16 and &NC& in production. So is there another way for them to get access to the data in the BDCP2 table that they do not know about or is this just something that we have to change, either with a table group change or a t-code?

Are they doing something incorrectly?

There are no entries in the BDCP or BDCPS tables,(both assigned to table group SA) just in the BDCP2 table

Any suggestions or information is appreciated

Thanks

Bobbi

1 ACCEPTED SOLUTION

Former Member
0 Kudos

Hi,

There are over 7000 SAP tables with &NC& Authorization Group (Authorization group 'blank' also checks for &NC& in authorization concept).

&NC& means "Not Classified" and groups all tables symbolically which cannot be otherwise classified. These tables are not financial relevant. Eventhough due to the large number of SAP tables being assigned under this auth group, it is reasonable to avoid giving &NC& access to users.

Here are your options for restricting access to only table BDCP2:

1. Assign custom auth group to this table via SE54 and give the access to it via S_TABU_DIS object

2. Have a custom view created for the table and protect the Z view via a custom auth group

As a matter of fact, in my previous implementation, we replaced &NC& with custom auth groups for many SAP tables and were successfully able to restrict access to many SAP delivered tables under this group without impacting the stability of the system.

Thanks

Sandipan

8 REPLIES 8

Former Member
0 Kudos

Hi,

There are over 7000 SAP tables with &NC& Authorization Group (Authorization group 'blank' also checks for &NC& in authorization concept).

&NC& means "Not Classified" and groups all tables symbolically which cannot be otherwise classified. These tables are not financial relevant. Eventhough due to the large number of SAP tables being assigned under this auth group, it is reasonable to avoid giving &NC& access to users.

Here are your options for restricting access to only table BDCP2:

1. Assign custom auth group to this table via SE54 and give the access to it via S_TABU_DIS object

2. Have a custom view created for the table and protect the Z view via a custom auth group

As a matter of fact, in my previous implementation, we replaced &NC& with custom auth groups for many SAP tables and were successfully able to restrict access to many SAP delivered tables under this group without impacting the stability of the system.

Thanks

Sandipan

0 Kudos

Thanks....I am aware of how to replace the auth group and assign that. I think my real question is before we do that, is there another way for the business to get the info other than direct access to BDCP2 table?

I just wonder why SAP assigned BDCP and BDCPS to a table group (SA) but not BDCP2.

If directly accessing BDCP2 is the correct and accepted way to get the data, then we can proceed with assigning it to a table group. I just was asking for validation that this is the correct approach and being sure there wouldn't be another way to get the data.

Thanks

Bobbi

0 Kudos

What particular data (table fields) you are looking from this table? Please let me know.

0 Kudos

These are the fields that display when you execute BDCP2 via SE16

Message Type Change pointer Process. indic. Table Name

0 Kudos

Hi,

Please see Sap Note 1165059 in case you use SAP_BASIS 701 or higher / 711 and higher.

If not, check tcode BD61 to activate Change Pointers globally. You may also check tcode BD52 and ensure the correct fields are configured to monitor for change pointers. This should get changes logged into BDCP/BDCPS

Thanks

Sandipan

Edited by: Sandipan Choudhury on Dec 30, 2010 12:24 AM

0 Kudos

Thanks I will pass that info along.

Is there a quick and easy answer to my question "Should they need to directly access the BDCP2 table?"

If reading the table via SE16 is a normal and expected part of job duties then I will proceed with requesting them to change the table group. If there is another way for them to get this data, can you tell me what that process would be?

Can anyone just answer that part of the question?

0 Kudos

Is there a quick and easy answer to my question "Should they need to directly access the BDCP2 table?"

My answer is YES as per the SAP note I mentioned above and note 305462.

As of Basis Release 6.10, change pointers may be stored in the new table BDCP2. Storage occurs in a type that allows faster access to the data.

As of Basis Release 701 and Basis Release 711, change pointers that are created using the SAP standard function modules are now stored only in the new storage location (table BDCP2)

Based on SAP release you are on and the facts in these note, you have to take the call. I don't see an other option to view change pointers except BDCP2 in Basis release 6.x systems.

My 2 cents:)

Thanks

Sandipan

Edited by: Sandipan Choudhury on Dec 30, 2010 1:22 AM

0 Kudos

Dear Bobbi,

There are lot of table not assigned in table group not means that SAP suggest you to use them directly in times of need. For your specific need can be fulfill by a custom code which should concentrate on gathering data from this table without S_TABU_DIS check. However depending nature of data this table have you may like to introduce few other authorization object on that program logic. But you can only figure out after knowing the gravity of importance of the data in the table and how business guys want to restrict them.

By the way if your users are not happy without access to SE16 then let them not be happy. Otherwise you won't be happy in future. And your functional guys can have these kind of access but have to be mitigated by some one else (greater authority).

Regards,

Arpan Paik