0

I would like to know what format the TID does look like?

We did a short reference implementation using the example StepByStepServer which is provided by SAP and there the TID serverCtx.getTID() has the following format:

TID : %_rGlkoiNMH2ox4aKWz/IBe5

The issue is that the TID may contain / and this will break the implementation of our Vendor that uses the TID-String to build a Filepath.

What does the TID look like in your implementations? Does they also have the format %_... and contain / ?

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
benniz
  • 146
  • 7

1 Answers1

0

A TID used by the tRfc and qRfc protocol should be a hexadecimal string of 24 characters. Allowed characters are [0..9], [A..F] or [a..f]. And it must be unique on the receiving system, therefore it also should be created and originate from this receiving system.

"%_rGlkoiNMH2ox4aKWz/IBe5" is not a valid TID. And I do not think that it was created by JCo. I would say, whoever is sending this TID, is doing it wrong.

Trixx
  • 1,796
  • 1
  • 15
  • 18
  • Hi, thanks for your feedback. We called 'API_CREATE_TID' and it is creating a valid TID within SAP. While debugging we found many Converter/Encoding-Classes and it seems the TID is converted by ConvertBEToC. Could it be an issue within the JCo when it converts the bytes to a string? – benniz Oct 05 '18 at 07:45
  • You must not call 'API_CREATE_TID' on your own. If you are on RFC client side, JCo offers the API JCoDestination.createTID() for getting a TID which is created from the partner side. Furthermore JCo internal converter classes are taboo and must not be used by Java applications. Only use public APIs which are also exposed in the JavaDoc. If your RFC client is on ABAP side, TIDs will be created automatically. Do not call 'API_CREATE_TID'. JCo does not create such a wrong TID. If you receive such a TID in a JCoServer application, then the bug is at the sender RFC client side for this call. – Trixx Oct 05 '18 at 09:25
  • Yeah the call to API_Create_TId was just to verify the correct generation. It is a JCoServer application and using Wireshark we saw that the TID %_.... is send from the SAP-System. Do you know what can cause this issue on SAP-Side? – benniz Oct 05 '18 at 12:34
  • A bug, of course. If this TID is coming from a SAP system, I recommend to create a support incident at SAP to get this fixed. – Trixx Oct 05 '18 at 12:44
  • We did some more testing and found out that this is related to the bgRFC. If we use tRFC the TID ist OK. But for bgRFC the TID is corrupt. It seems that for bgRFC we need to use the UnitIdentifier instead of the TID – benniz Oct 08 '18 at 18:41
  • Of course, a TID and a background unit ID are different things. But if using the bgRfc you won't get a TID and serverCtx.getTID() returns null. No one can help you here as you do not tell what you are doing. It is even not clear if your sending SAP system is an ABAP system, a Java system or something else. – Trixx Oct 08 '18 at 19:28