Reproduzierbare GUID aus String
11 Beiträge
•
Seite 1 von 1
11 Beiträge
Seite 1 von 1
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wenn es nur darum geht einen reproduzierbaren Wert aus einem String zu generieren, ohne jetzt den detailierten Anforderungen aus RFC4122 zu genügen, reicht meines Erachtens ein MD5-Hash.
z.B. Mit CL_ABAP_MESSAGE_DIGEST=>CALCULATE_HASH_FOR_CHAR ist das Ergebnis ein 32 Zeichen langer String der einer GUID im ABAP ähnelt.
z.B. Mit CL_ABAP_MESSAGE_DIGEST=>CALCULATE_HASH_FOR_CHAR ist das Ergebnis ein 32 Zeichen langer String der einer GUID im ABAP ähnelt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Hallo,
OK, damit bekomme ich schon mal einen SHA-1 Hash. Aber letztendlich brauche ich trotzdem eine RFC4122 konforme GUID. Der Wert landet später in einem Feld vom Type "uniqueidentifier" einer MSSQL Tabelle.
OK, damit bekomme ich schon mal einen SHA-1 Hash. Aber letztendlich brauche ich trotzdem eine RFC4122 konforme GUID. Der Wert landet später in einem Feld vom Type "uniqueidentifier" einer MSSQL Tabelle.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Wie gesagt: Nimm statt SHA1 den MD5 und schon hast du einen 32 Zeichen langen, "eindeutigen", Identifier. Die Formatierung XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX musst du sowieso selber machen, weil SAP, auch bei GUIDs die dem RFC entsprechen, die Bindestriche weglässt.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Mit CL_SYSTEM_UUID=>CONVERT_UUID_C32 kann man sich übrigens die Formatierung laut dem RFC auch von SAP aufbereiten lassen. Vorraussetzung ist wie gesagt der 32 Zeichen lange Identifier. Einzige die Kleinschreibung der Buchstaben muss danach noch gemacht werden.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Ja, das ist eine GUID an sich, aber nicht die Name-based Variante.ewx hat geschrieben: ↑25.01.2024 11:30https://gist.github.com/larshp/e99d9dcd ... 048a52276b
https://answers.sap.com/questions/11928 ... -abap.html
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
damit bin ich leider immer noch nicht RFC4122 konform. Ich hab mir nun in Anlehnung an das von ewx erwähnte gist was gebaut, das soweit funktioniert (works for me :-) )a-dead-trousers hat geschrieben: ↑25.01.2024 10:58Wie gesagt: Nimm statt SHA1 den MD5 und schon hast du einen 32 Zeichen langen, "eindeutigen", Identifier. Die Formatierung XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX musst du sowieso selber machen, weil SAP, auch bei GUIDs die dem RFC entsprechen, die Bindestriche weglässt.
Code: Alles auswählen.
CLASS lcl_guid DEFINITION.
PUBLIC SECTION.
CLASS-METHODS gen_guid IMPORTING i_namespace TYPE sysuuid_x16
i_data TYPE string
RETURNING VALUE(r_guid) TYPE sysuuid_x16.
ENDCLASS.
CLASS lcl_guid IMPLEMENTATION.
METHOD gen_guid.
DATA hash TYPE x LENGTH 16.
DATA(xdata) = cl_abap_codepage=>convert_to( source = i_data ).
CONCATENATE i_namespace xdata INTO DATA(payload) IN BYTE MODE.
cl_abap_message_digest=>calculate_hash_for_raw( EXPORTING if_data = payload
IMPORTING ef_hashx = hash ).
" set Version to 5 (= SHA-1 based GUID)
SET BIT 1 OF hash+6(1) TO 0.
SET BIT 2 OF hash+6(1) TO 1.
SET BIT 3 OF hash+6(1) TO 0.
SET BIT 4 OF hash+6(1) TO 1.
SET BIT 1 OF hash+8(1) TO 1.
SET BIT 2 OF hash+8(1) TO 0.
r_guid = hash.
ENDMETHOD.
ENDCLASS.
Beitrag
von a-dead-trousers (Top Expert / 4395 / 223 /
1182
)
»
Vorsicht: Das Ergebnis von SHA1 ist X20 und nicht X16. Bei deinem Beispiel wird somit etwas abgeschnitten und ist damit nicht mehr "eindeutig". Deswegen meinte ich ja, dass du besser MD5 nehmen solltest.
EDIT:
Nevermind. Der RFC besagt, dass man SHA-1 standardmäßig nehmen soll und es wird dann halt Bit für Bit kopiert. Eine solche UUID ist dann somit aber nicht mehr *wirklich* eindeutig.
Eine Sache noch zum Namespace. Im Standard steht, dass man für den Namespace selbst zuerst eine UUID generieren und diese über ein Art von Register verwalten muss. Also für jeden neuen Namespace eine neue (random) UUID generieren. Um jetzt wirklich korrekt zu sein, würde ich mal annehmen, dass man den Namen vor dem Concatenate in Unicode-Systemen in ISO-8859 umwandeln sollte und dann erst weiterverabeiten darf. Sonst hat man ja keine Grundlage, die auf allen Systemen eine idente UUID liefert. Alternativ müssen alle beteiligten Systeme die gleiche Codepage verwenden um die gleiche UUID generieren zu können. Der Standard umschreibt das hier nur sehr vage:
EDIT:
Nevermind. Der RFC besagt, dass man SHA-1 standardmäßig nehmen soll und es wird dann halt Bit für Bit kopiert. Eine solche UUID ist dann somit aber nicht mehr *wirklich* eindeutig.
Eine Sache noch zum Namespace. Im Standard steht, dass man für den Namespace selbst zuerst eine UUID generieren und diese über ein Art von Register verwalten muss. Also für jeden neuen Namespace eine neue (random) UUID generieren. Um jetzt wirklich korrekt zu sein, würde ich mal annehmen, dass man den Namen vor dem Concatenate in Unicode-Systemen in ISO-8859 umwandeln sollte und dann erst weiterverabeiten darf. Sonst hat man ja keine Grundlage, die auf allen Systemen eine idente UUID liefert. Alternativ müssen alle beteiligten Systeme die gleiche Codepage verwenden um die gleiche UUID generieren zu können. Der Standard umschreibt das hier nur sehr vage:
The mechanisms or conventions used for allocating names and ensuring their uniqueness within their name spaces are beyond the scope of this specification.
Theory is when you know something, but it doesn't work.
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Practice is when something works, but you don't know why.
Programmers combine theory and practice: Nothing works and they don't know why.
ECC: 6.18
Basis: 7.50
Beitrag
von black_adept (Top Expert / 4087 / 126 /
940
)
»
Nimm den String selber als GUID. Das spart ne Menge Arbeit.
Hallo,
ich hab meinen Code von oben grad noch mal gegengecheckt mit einer Implementierung in Go (mit dem google uuid Modul) - die generierten GUIDs sind identisch. Somit sollte mein ABAP Code von oben schon passen.
Nur einen MD5 oder SHA1 Hash generieren und vier "-" reinbasten wollte ich nicht. Solange man die Hand über allen beteiligten Systemen hat, kann man das sicher verantworten. In meinem Fall verlassen die Datensätze mit der GUID das SAP und ich kann nicht sagen, ob das empfangende System jetzt oder in Zukunft die GUIDs auf Konformität mit RFC4122 prüft.
Wegen der Codepage mach ich mir keine Sorgen - Die Default-Codepage bei cl_abap_codepage=>convert_to( ) ist UTF-8.
Hier der Go Code:
ich hab meinen Code von oben grad noch mal gegengecheckt mit einer Implementierung in Go (mit dem google uuid Modul) - die generierten GUIDs sind identisch. Somit sollte mein ABAP Code von oben schon passen.
Nur einen MD5 oder SHA1 Hash generieren und vier "-" reinbasten wollte ich nicht. Solange man die Hand über allen beteiligten Systemen hat, kann man das sicher verantworten. In meinem Fall verlassen die Datensätze mit der GUID das SAP und ich kann nicht sagen, ob das empfangende System jetzt oder in Zukunft die GUIDs auf Konformität mit RFC4122 prüft.
Wegen der Codepage mach ich mir keine Sorgen - Die Default-Codepage bei cl_abap_codepage=>convert_to( ) ist UTF-8.
Hier der Go Code:
Code: Alles auswählen.
package main
import (
"fmt"
"github.com/google/uuid"
)
const namespace_guid = "94DBC7F9-7280-1EEE-AEEC-354F9EBD9321"
func main() {
teststrings := []string{"Test", "123", "Täst", ":://?? öüÖÜ"}
namespace := uuid.MustParse(namespace_guid)
for _, v := range teststrings {
id := uuid.NewSHA1(namespace, []byte(v))
fmt.Println(v, "=>", id)
}
}
Seite 1 von 1
Vergleichbare Themen
13
Antw.
Antw.
4378
Views
Views
3
Antw.
Antw.
2058
Views
Views
5
Antw.
Antw.
5138
Views
Views
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 990
vor 2 Tagen von DeathAndPain 4 / 990
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 990
vor 2 Tagen von DeathAndPain 4 / 990