GUID Should NOT Always be Generated

GUID random data

GUID random data

I recently had a conversation about integrating a system that had a unique key for its business objects, and about methods of doing integrations.


The receive system used GUID for all the objects it created – this is much like SAP Cloud 4 Customer (C4C).


A GUID is a globally unique identifier, which you may also recognize as the implementation of the UUID (universally unique identifier). It is a 128-bit long, randomly generated data. 6 of the bytes are fixed to make sure that the indicated data is random. The goal is to never create the same value twice, so no matter which system you are integrating with, you will never see the same value for any objects. This makes a lot of sense when you have different systems creating messages and objects. This way they can easily create unique objects.

We often see it formatted as a Hex (hexadecimal) string in the following format:



The scenario is that you have a customer in a system, and you want to synchronise this with the target system using the GUID key. The customer number is 12000244.

You can ignore the key for some objects, and the target system may generate it by itself. You can also generate a GUID for the object and set it up for it. With any of these solutions, you have an issue if you have to update this object.


You cannot update customer ID 12000244 – you would have to look up the GUID for this object. This is possible because the target system has the value, so you can easily look it up. But it will require an extra lookup. The GUID can also be updated back at the source system, so it can send the same GUID next time it runs.


If I’m in a PI message context, then I may just use the PI Message ID because it is much easier to get, and I don’t need to create a special Java function.


A different approach is to generate the GUID with a sense of purpose, so we don’t have to store the GUID. This can be achieved by having a value like:


In this case, the GUID would look like:



You can make your own naming, which will fit your object. I would recommend that you create this as a UDF (user-defined function), so you don’t have to do the formatting each time you will use this kind of integration.


If you have two synchronisations, you will have to look up the value coming from the GUID system. Then the object has already been created there, so you would  have to do the lookup for that customer. Hopefully, they will have a different numbering, or some other way to identify what you have.


On a related note, I believe that I once had a requirement to store the GUID from a message exchanged with partners in a 20-character field. I cannot remember the exact requirement and the reason why we needed the value. I found that it was possible by getting the binary value for the GUID, and then packing it as BASE64. I also had a web app that could do the reverse function.

So just remember to think about this if you need to generate GUIDs. Maybe you can solve this some other way.


Comments are closed.