Question
Jabil
US
Last activity: 15 Apr 2016 9:57 EDT
Are there plans to bake in native OData support for more robust JSON interactions?
Using the handy engine API to auto-map JSON to PRPC objects, it throws errors with OData markup. Any number of workarounds we can use for this, but are there plans to natively understand OData? Seems like a big opportunity as so many large enterprise tools now employ it.
Accepted Solution
Jabil
US
After much more experience I will offer my own answer. We found the OOB integration usage pattern to have two fundamental deficiencies that prevent it from being employed as designed in many enterprise situations.
- Connect-REST encodes URL parameters too aggressively. To comply with the spirit of the RFC and avoid, for example, replacing valid spaces with %32 (in my context these are server API instructions, not user input), we should at least have the option to use URI encode instead of URL encode (or not encode at all). This means we cannot use the rule's parameterized URL construction as intended. Instead we must put everything up in the URL line and a different Connect-REST rule for each situation.
- The Engine API Clipboard.adoptJSONObject/Array assumes that the JSON response contains keys that are all valid Java identifiers. Frequently ODATA uses @ signs as key-name prefixes for metadata, so making the JSON option in the Connect-REST rule unusable. The only alternative is to map to Clipboard, manipulate the response string, and then call adoptJSONObject in a Java step or function call.
Hope this helps someone.
PEG
IN
I think we can use Connect-REST to connect to ODATA Services. In 7.x Connect-REST has been enhanced. You can give it a try with Connect-REST.
Accepted Solution
Jabil
US
After much more experience I will offer my own answer. We found the OOB integration usage pattern to have two fundamental deficiencies that prevent it from being employed as designed in many enterprise situations.
- Connect-REST encodes URL parameters too aggressively. To comply with the spirit of the RFC and avoid, for example, replacing valid spaces with %32 (in my context these are server API instructions, not user input), we should at least have the option to use URI encode instead of URL encode (or not encode at all). This means we cannot use the rule's parameterized URL construction as intended. Instead we must put everything up in the URL line and a different Connect-REST rule for each situation.
- The Engine API Clipboard.adoptJSONObject/Array assumes that the JSON response contains keys that are all valid Java identifiers. Frequently ODATA uses @ signs as key-name prefixes for metadata, so making the JSON option in the Connect-REST rule unusable. The only alternative is to map to Clipboard, manipulate the response string, and then call adoptJSONObject in a Java step or function call.
Hope this helps someone.