Idea Details

RESTful API supports 64bit data values

Last activity 06-13-2019 09:36 AM
Andre Heller's profile image
02-03-2015 09:46 AM

What is the use case of the new feature?

----------------------------------------

Customer wants to create custom events by the RESTful-WS API in the related custom event code ID range (0xfff0000 upwards). E.g. like in the Event Configuration GUI or at the file base.

 

Describe the new feature in detail

----------------------------------

The RestAPI converts the event codes from Hexadecimal to integer in Java. In Java, an integer can have a maximum value of 2,147,483,647 (signed int 32 bit). If a user wants to convert an event code in the custom event ID range like 0xffff0002, the conversion results into a decimal value of 4,294,901,762 which is greater than the MAX integer value in JAVA. Engineering confirmed this is FAD for the RestAPI.

But that means the RestAPI will not work for events whose event codes are greater than 0x7fffffff and in result for the custom event ID ranges.

The RestAPI should be able to cover all of the possible value ranges of the spectrum data model.

 

Describe how you envision this new feature being implemented.

-------------------------------------------------------------

The RestAPI should use 64bit data types or data types which covers all of the possible value ranges of the spectrum data model.

 

What business problem will be solved by adding this new feature?

----------------------------------------------------------------

Users are able to use the RESTful-API as suggested by the documentation and without any undocumented limits. The API makes the CA Spectrum data model accessible to many different external development environments and methods.

 

Describe the importance and urgency

-----------------------------------

The described problem limits the possibilities of the RESTful API feature. In certain cases the RESTful API is not usable as by the limit.

Importance: high

Urgency: high


Comments

08-06-2018 08:27 AM

I have tested in 10.2.3  using event id 0xffffffff and it worked.

 

Joe

08-01-2018 06:23 AM

This has been addressed in Spectrum 10.2.3 

 

Regards, 

AmitMohanty1

06-26-2018 10:07 AM

Nagesh_Jaiswal kiran_diwakar

Can you guys pipe in here and let us know the status of this idea?

06-26-2018 09:53 AM

Unfortunately this has not been fixed. This forces us to use events in the CA range with all its associated risks....

12-05-2017 06:43 AM

Bug not fixed since 2015. Fantastic.

10-27-2017 02:05 AM

Does not work as expected = BUG :-{

03-10-2017 11:08 AM

Actually, it's not even 64 bit values that need to be supported since event IDs and model handles in Spectrum aren't 64 bit but rather unsigned 32 bit values.  Java didn't support unsigned 32 bit integers before Java 8 but it does now:

 

Primitive Data Types (The Java™ Tutorials > Learning the Java Language > Language Basics) 

 

int: By default, the int data type is a 32-bit signed two's complement integer, which has a minimum value of -231 and a maximum value of 231-1. In Java SE 8 and later, you can use the int data type to represent an unsigned 32-bit integer, which has a minimum value of 0 and a maximum value of 232-1. Use the Integer class to use int data type as an unsigned integer. See the section The Number Classes for more information. Static methods like compareUnsigned, divideUnsigned etc have been added to the Integer class to support the arithmetic operations for unsigned integers.

03-10-2017 10:53 AM

Still not fixed in 10.2 ...

11-16-2015 03:25 PM

Maybe we are lucky and it is fixed in 10.1.

11-16-2015 12:58 PM

for me, it is a bug...

11-16-2015 12:45 PM

I ran into this prototyping an external custom application that will interface to Spectrum v10 using RestFull and thought I was going mad until I found this topic discussed here & Joe Ackley's answer to Alex's question too (Custom Event via REST API ).

With our customer(s) over the years we have established 0xfff0nnnn as a suitable range for many 100s of custom events, as a 'standard' to keep them away from CA's own and vendor-reserved ranges. But for use of Restful interface it seems we may have to renumber all, or big subsets of, the custom events' codes to a different range. What a pain!

It is poor that this has to be an "idea" to get listened to, especially given the 64bit  bally-hoo around Spectrum v10.

Cheers, Dan.

09-10-2015 02:03 PM

For me is a bug. If spectrum suports 64 bits values the REST API must support too.

08-05-2015 03:55 AM

I think another thing to think of for the developers, is to use one format and then stick with it. I've worked on Spectrum for a while, and it's silly to have model_handle expressed in some places as a hexidecimal number, and then other places it's represented by using a decimal. Use one format and stick with it.

08-05-2015 03:09 AM

Thanks for your feedback. We had a long discussion with the support and SE. But in result we had to open an idea to enhance the current design. Unfortunately the result was not influenced by the fact, that the RESTful API is not able to support documented standard stuff of spectrum.

Maybe we are at the same point as Define the difference between a Defect and Enhancement ... this idea is currently under review. So hopefully we will get a statement soon how CA wants to handle such cases in the future.

08-04-2015 10:59 AM

Personally, I would consider this a bug.  I don't care if the developer intentionally chose to use a poorly sized variable, if the allowed range of event IDs exceeds what the RESTful API is able to access, that's broken.