Why do we need GUID?

[Former Member]

Hi All,

I noticed some posts on SDN forums talking about creating GUIDs and using them as primary keys in DB tables and Persistent Objects especially in CRM.

But I don't know why do we need GUID? aint the business key enough?

What are the uses of GUID?

I could not find any GUID fields in the standard tables in our ERP system (SAP NetWeaver 7.0)!!!

Could somebody please explain this to me or put some links on this matter.

[Former Member]

GUID means Global Unique Identifier. You use a GUID when you need to identify an object/component with a unique id.

GUID are 128-bit object identifier calculated using an algorithm defined by the Open Software Foundation.

GUID is based on the same standard as a UUID.

UUID is:

Universal Unique Identifier. Global unique identifier that is generated from the system time stamp and the network address according to one of the Open Software Foundation standards. The methods of the CL_SYSTEM_UUID class create UUIDs in different formats and allow for the conversion from one format to another.

You can use Function Module SYSTEM_UUID_CREATE to generate GUID of type SYSUUID-X (raw 16 (compressed value of char 32))

Reward points if useful.

[Kanagaraja_L]

GUID means Global Unique Identifier. You use a GUID when you need to identify an object/component with a unique id. GUID is a unique key for any object in CRM.It is of 32 char and hexadecimal in nature,2 types of GUIDs Header & item.For header, there will be a unique GUID and for each item-line, there will be another unique GUID.

GUID is based on the same standard as a UUID.

Universal Unique Identifier. Global unique identifier that is generated from the system time stamp and the network address.Use the Function Module SYSTEM_UUID_CREATE and SYSTEM_UUID_C_CREATE to generate GUID of type SYSUUID.

Kanagaraja L

[Former Member]

Hi Mustafa,

The advantage I can see of using GUIDs as against business keys is that all data access and update in the back end takes place using the GUID. This is a part of the new SAP concept of accessing database tables through persistence layer/services.

This in a way improves performance of DB access/update, however, when users enter data, they always enter the business key, but internally SAP code is designed to retrieve the GUID and query all related transaction tables with the GUID which is saved in RAW format and is hence better from SQL perspective.

The user is always hidden from the GUID and never sees it, however internally all operations take place based on this.

Regards,

Aditya

[uwe_schieferstein]

Hello Mustafa

The previous postings explained the GUID in detail.

The only thing I like to add is - since you posted your question in this particular forum - is to mention the class CL_RECA_GUID (available on >= ECC 5.0).

In table DD03L you will find more than 2000 table fields named GUID, approximately 600 of them are key fields (on ECC 6.0).

Example: DB table CGPL_TASK (Project Planning: Attribute Table for Activities)

I think a unique GUID makes sense when either the "normal" business key becomes to complex to use or if business objects are shared between different SAP systems (e.g. you may have an EBP systems and your "normal" R/3 ERP system).

Regards,

Uwe

[Former Member]

Thank you all for your helpful replies. As I mentioned in my message above I’ve read many posts on this subject and understood the concept of GUID but what I am really looking for is the need for GUIDs. Probably, Uwe’s point regarding sharing business objects between multiple systems is the most meaningful use to me.

Another point that makes sense is Aditya’s remark on persistence services and hiding the database accesses. Different business objects of different types may share the same key format and hence may have the same business key although they are of different types and are stored in different tables. But when we deal with them as ABAP Objects we need to uniquely identify one business object; we can do that using GUID.

Thanks again for your replies. You deserve some points.