JCO reading abap RAW data type (truncating?)

[Former Member]

Does anyone have experience reading an Abap RAW data type using JCO?  I am trying to read a GUID (via RFC_READ_TABLE) that is defined as RAW length 16.  When I view this field in SAP GUI, I see 32 characters.  However, when I read this field using JCO, I only see the first 16 characters. 

The mapping documents state Abap RAW maps to a Java byte array.  I have tried that - no luck.  I have used the constructor of a string that takes a byte array - no luck.  I have made sure my character set is UTF-8 in case Unicode was a possibility.  I have turned on tracing to level 8 and only see 16 characters in the output.  I need the other 16 characters as all 32 characters are used as the primary key into other tables.

I also posted this on the ABAP Java Development space.  I know the rule about not cross-posting, but I wasn't sure which was a better place to post something like this.  This my first post on here, so my apologies in advance.

Larry

[Former Member]

Hi,

com.sap....JCO.Table testTable = funct.getExportParameterList().getTable("XXXX"); where XXXX is the exportParameter of the FM

byte[] testGuid  =  testTable..getByteArray("GUID");

regards

Jagdeshwar,

[Former Member]

Thanks for responding.  Unfortunately, the export parameter list is null. There are no export parameters.  However, there are tables.  I have tried:

byte[] byteArray = funct.getTableParameterList().getTable("DATA").getByteArray(0);

My SE16 query only returns one field: GUID.

I only get 16 bytes back even though GUID is defined as raw length 32.

Is there something I else I should try?  Do you see an error in my code?

Thanks again,

Larry

[MarkusTolksdorf]

Hi Larry,

do not use RFC_READ_TABLE. This is not only from security perspective a bad choice, but also from design point of view. Use or create a dedicated remote enabled function module that is reading the data from the database within ABAP and define a typed interface for it. Then you will not run into troubles. RFC_READ_TABLE is a generic function module that does not really care about the data types of the tables in use.

Best regards,

Markus

[Former Member]

Hi Markus,

We are in a resource-constrained environment and trying to access our corporate data without IT assistance.  We don't have the ability (security permission) to write our own function modules - that has to be done by IT.  We have been using RFC_READ_TABLE to access our HR/Payroll data for quite a while.  I am now trying to access CRM data.  The RFC is there.  The problem is the GUID is needed  when querying the child tables as it's been propogated down to them.  If I can't resolve this issue, yes, we'll definitely ask them to build a wrapper function for us ($$$).

Thanks,

Larry

[MarkusTolksdorf]

Hi Larry,

I must admit that I'm really surpised that you're allowed to read such sensitive data like payroll or HR data without authority checks - because RFC_READ_TABLE will bypass such checks that are done by the HR/Payroll function modules. I can only recommend to do it the other way - it's much cleaner.

Best regards,

Markus

[Former Member]

I understand.  I work in Payroll and our program's user ID has the ability to do most of the same things a privileged Payroll user could do.  The one thing we can't do is change data since you would want to have the actual human user on the record as the one who actually changed it.  IT actually recommended the RFC to us to access Payroll/HR data.  From what I understand, there are edits on the SAP end to prevent us from looking at things we're not allowed to (which isn't much).

Thanks,

Larry