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: 

block individual field within a table

Former Member
0 Kudos

Hello everyone,

Is there an option to block a specific field within a table observed by SE16, without building a "view" for it?

I'll explain myselfu2026. There is a table containing credit card numbers, but this table also containing critical data for my client, that can not be drawn from elsewhere.

I'm looking for an option that would allow him to watch the whole table through the SE16 , without the credit card numbers.

Thanks,

Julia

6 REPLIES 6

Former Member
0 Kudos

Hi Julia,

The alternative option is to use SAP Queries using SQVI transaction code. You have an option to select the required fields for the table.

Further, you can assign the query to a transaction code in SE93 and assign the same to the users. Below are the steps to create a transaction code.

1. Goto SE93

2. Enter the transaction code name and description.

3. Select the option "Transaction with Parameters"

4. Transaction should be START_TRANSACTION.

5. Check Skip initial screen

6. Under the default values, enter the following:

D_SREPOVARI-REPORTTYPE AQ

D_SREPOVARI-EXTDREPORT Query name

D_SREPOVARI-REPORT Query user group to restrict (not SU01 user groups)

However, the users should be assigned to the query user groups. These are further maintained using SQ03 transaction code.

Ofcourse, my recommendation would be to stick to SE16 views and restrict the authorization to the table views

Hope this helps!!

Regards,

Raghu

Former Member
0 Kudos

A restricted view and parameter transaction is a better option than further complicating the authorization concept.

Even better for CC numbers is tokenization of the fields - they can display them from data browsers but it means naught to them.

Cheers,

Julius

former_member202002
Active Participant
0 Kudos

As Julius mentions, tokenization is a good approach for this as it replaces the RAW Credit Card Number at the database field level with a "token". This token typically contains the last 4 digits of the original Credit Card Number and is essentially a pointer in an external database where the encrypted credit card number is stored.

A user would therefore only see the token, whether in SE16 or the Order Entry Payment Card screen (VA01\VA02\VA03) or any other screen in which credit card numbers are displayed.

I'd recommend you look at the various SAP certified credit card middleware vendors listed on Ecohub as they all have tokenization solutions.

0 Kudos

Hi Eric,

While looking at the tokenization, I find some nice information on XISecure. I had looked at the video too and yes it might be a good solution to mask the credit card/any sensative information in the system.

Thanks to you and Julius for this new piece of information I had configured a similar tool - TDMS (Test Data Migration System) which is used to migrate the data from production to the other systems such as Q, and T with dummy data. But, didn't know about the tokenization that can mask the sensative data in the same system.

My learning book had been updated with this piece of cake

Regards,

Raghu

0 Kudos

Hi Raghu,

check best practices for tokenization and other related documents from Visa. Not directly related to SAP but useful.

Cheers

Former Member
0 Kudos

Thank you everybody for you very helpful answers, I will really consider to use the tokenization option.

Raghu- good luck with the TDMS