GUID Function needed for REST POST endpoints

[ACDC]

When configuring a REST setup and utilizing the POST method to create a new entry, it's often necessary to provide a unique identifier in the target application. It would be highly beneficial to have a function that can generate a GUID specifically for this purpose. The AwareIM ID attribute may not suffice as it's not guaranteed to be unique. Hence, incorporating a GUID generation function into the AwareIM function lineup would be a logical solution.

[joben]

This might help until such a function is implemented. It will create a random hexadecimal value, 32 characters long.

If Bo IS NEW Then
Bo.guid=TO_LOWER_CASE(MD5(GENERATE_PWD(8,15,2,2,2)))

Result:
34cadc59f6f83b775468ae1a91ad4380

[ACDC]

Thank you, this will work for me .

What are your thoughts about inserting a timestamp in the formula ?

[joben]

I guess it depends on what you want to accomplish.
With the provided example you get:

• Randomness
• Low risk of collision
• Correct bit length according to the standards

I always assumed typical guids were just randomly generated hexadecimal values like:
34cadc59f6f83b775468ae1a91ad4380
And to follow the standards they need this fancy separation:
34cadc59-f6f8-3b77-5468-ae1a91ad4380

But I just learnt that some of the standards do include non-random data like time and date.
So once again, it depends on what needs to be achieved. I don't have any experience with a case where the numbers matter as long as they are random and unique.

[hpl123]

Another option is using the Aware ENCRYPT_B64 function which can be used to encrypt/store in a string whatever data you want so identifier, timestamp and whatever else you want. I don´t know if the resulting string fits all API related calls and requirements but would think it does. I use this extensively and works very well for all kinds of things. The only thing I would ideally want is a "real" encryption instead of the B64 one and hoping support can add that at some point.

[ACDC]

In my case, I want to include the Object.ID as part of the remote GUID, so at any time I can backtrack where the transaction came from.
both seem to be good options, Thanks again