Issue
I want to implement an interface to IFS by using RESTful APIs. In my specific case I want to query IFS for customers via REST. I am using the projection CustomerHandling to GET information for a given customer number. We have developed several custom objects within the LU CustomerInfo and some of them being custom enumerations. If I query IFS for the customer, I get a JSON result containing all fields of that LU but with the issue that the enumerations do not contain the value they show in the IFS client. The database has the correct value too. Only via REST the Enums return something else. In fact, I don't know what the value should represent.
Please find attached two screenshots.
One showing the custom fields (dropdown list) in the IFS enterprise explorer and the other showing the JSON result I get when querying IFS via REST for the same customer.
Note:
I do receive the same JSON result when posting the REST URL into a browser.
URL: https://vsm-test.ifs.cloud:48080/main/ifsapplications/projection/v1/CustomerHandling.svc/CustomerInfoSet?$filter=CustomerId%20eq%20%279390%27 for our Test environment.
The following URL also has this same issue.
URL: https://community.ifs.com/ideas/improve-enumeration-handling-in-projections-13822
We need to be able to read and write the actual values from custom enumerations via REST. I assume we would have problems setting values to custom fields having enumerations because of that issue. Please let me know what you will do to analyze and solve the problem or if you need more information.
Resolution
Explanation:
- The values you are seeing here are enumeration type member (Enum) names, which are values we expose in OData document as well ($metadata). Those are generated at the server logic by prefixing 'CfEnum_' section to DB value. Main reason for this prefixing is to generate a valid member name as defined in OData protocol itself.
- Here, as per the OData protocol, in data responses, we correctly provide the name of the member (as defined in OData document) for custom enumerations, thus we do not see any fault in the observation.
- As I mentioned the service endpoints are already adhered to OData protocol, hence no changes are needed in this functionality. In other words, there is no other way we are required to expose any client or DB values of such enumerations.
- By following OData protocol, consumers should already be able to interpret these values correctly.
But the real question was "How can I translate "CfEnum_M" to "Metric" via REST?".
Answer for this question was provided according to the Cloud version and refer the following explanation.
- If client integrations would like to get Client / DB Values of Enums via REST, you can use EntityHanlding API for this purpose.
- endpoint: EntityHandling.svc/DictionarySysLus(LuName=<enumeration_name>)/DictionarySysDomainArray?$select=DbValue,ClientValue
- In addition, this information is already available on the IFS Cloud client Solution Manager / System Information and Utilities / Entity page.
Customer is using IFS Apps 10, not IFS Cloud. If we browse the API Explorer for EntityHandling.svc we didn't get any result. In Apps10, the exact API (EntityHandling) is not there. But to get values from the application, you can use the "Logical Units" page. See the following attachment.
Further explanation in APPS 10:
- As per ODP standard we respond using the Enum IDs. We can't use the DB value directly as an identifier can start with numbers.
- If the custom knows the DB Values, the Enum identifier will be "CfEnum_<DB_Value>". For example, Specialist is the Client value, we can't use Client Values as they are translatable.
- Suggestion is to avoid using client values in the client server communication. the option is to have clearer DB values, like "SPECIALIST" instead of "SPZ" (This is included in one of your attachments) as the definition for the Enum identifier is "CfEnum_<DB_Value>".
- This is how the current system is working and according to our internal Product Development team, no major change will be implemented to the system as this is according to the guidelines.