A nice new feature in the latest PLM 360 update is that REST API will show more detailed error information for when a add/update operation fails because of bad field data. For example, if you try to update an item with a value of “x” for a numeric field, you will now get an error specifying which field(s) failed and why.
First, let’s go over the generic error case. For example, if you try to add a new item to a workgroup you don’t have write access to, here is the JSON error data you will get back. The structure corresponds to the APIError class in the API documentation.
| { "errorCode":"SEC_FORBIDDEN", "message":"Access Denied.", "params":null, "url":null, "errorClass":"APIError" } |
Now let’s look at the case where you try setting a field to a value that is not allowed. Here is the JSON that you get back, which corresponds to the FieldValidation error class.
| { "errorCode":"ITEM_VALIDATION_FAILED", "message":"Item validation failed.", "params":null, "url":null, "errorClass":"FieldValidationError", "fieldErrors": [ { "fieldId":"CURRENCY", "errorDescription":"Currency is not a valid currency amount" }, { "fieldId":"DECIMAL", "errorDescription":"Decimal must be a valid decimal number with at most 2 decimal digits." }] } |
The first thing to note is that the FieldValidation data is a superset of the APIError data. Another way to putting it is that FieldValidation is a subclass of APIError. That means that PLM errors follow a similar pattern to Java and .NET Exceptions. In those languages, Exception is the base class and specialized subclasses exist for specialized cases (IOException, StackOverflowException, and so on). You as a programmer can handle things in multiple ways depending on how specialized the error is. In PLM, APIError is the generic case and FieldValidationError is a specialized case. More specialized errors may be added in the future, but for now, there is just one case.
Another thing to note is that the errorClass property matches the name of the error class. This is to help your code deserialize to the correct object. It’s a bit of a circular problem because you need to deserialize the JSON in order to figure out how the JSON should best be deserialized.
I recommend a multi-phase approach to handing errors.
- In the event of an error (HTTP codes in the 400s or 500s), read the HTTP body into a string.
- Deserialize the string into an APIError object.
- Check the “errorClass” value.
- If errorClass is not APIError, deserialize again to the proper error class.
After that it's up to you how you want to use that error data. But you definately have more options than you did before.
Leave a Reply