Team, want to check on these 2 aspects, which we are attempting to leverage in our Appian solution implementation.
1) We are building a solution to retrieve specific data using XPATH from an XML and mapping it to a target location.
We will be using the "xpathdocument" function in Appian to fetch the value from XML.
2) We will also be leveraging the below function to obtain our XML.
--- something like this ---
local!apoPbj: a!fromJson(ri!ipJson)
local!xmlObj: toxml(local!apoPbj, true, "xml")
3) Data will be fetched from XML using the 'xpathdocument' method as we mentioned above.
This looks working good when tested.
Question:
1) But I see currently "xpathdocument" method supports only XPATH 1.0. Does Appian have plan to support the newest XPATH version down the line?
2) Do you see any limitations in the above strategy?
Discussion posts and replies are publicly visible
1) Who knows ... I am sure this is somewhere on the list of improvements we are all waiting for. If you can turn this into a valuable business case, then contact Appian for a product improvement.
2) Why not just stay with JSON? Adding XML to the game does not make sense from my perspective, not knowing the details of your use case.
Thanks for answering the first question.
I personally had some past experiences that XPATH 2 or 3 - had little more ability and readability to fetch and parse values from a XML rather what JSONPATH could do with JSON. Could be a personal perspective too. But with JSON path evolving, it too can overcome XPATH sooner.
So we went with XPATH in case we will get a chance to leverage the latest version of XPATH parsers available in case from Appian.
Let me see how we can raise a Product improvement request on this. We may not keep using the XPATH strategy as a policy decision in future implementations. But I thought it would be powerful had Appian supported the latest XPATH parsing versions.
Its great to interact with you. Appreciate your insights.
Help me understand your use case. If it is just about mapping data from incoming data to use somewhere in Appian, you will not need any sophisticated XML parsing. And if the incoming data is JSON, stay with JSON. Use fromJson() to parse it into a dictionary and you can easily work with it using normal Appian code.
This is where we exactly started with - Like converting json to dictionary object and writing to an excel template from there.
But we wanted the ability to provide a user driven configuration so that our business users decides the mapping of source and target data points.
We are implementing an excel writing ability - where the data from source gets mapped to different cells of an excel template (in multiple sheets). These excel templates could change and we want business to have the ability to drive the source (json or xml) data points and target excel cell where it should go.
So we extracted the ability to manage the source (xpath data points) and target (cells) to go into a Appian table which business can maintain.
So the Appian code to write to excel template will be agnostic and will just pick and write the data from the driver table and maps the data to the excel cells based on the configuration.
In this case - business world understands XML XPATH better so that they configure or make the changes by themselves in a table.
Doesn't this sound little interesting?
This sounds crazy ;-)
I understand your user case. Thanks for the explanation.
Question - Do you like this though?
The way we intending to keep the Appian code agnostic and dynamic.
So a business user controls the mapping for any different kind of templates.
I am not a fan of any use case that involves Excel, but sometimes it is what has to be done. So if, for whatever reason, your business users need to map some data to Excel exports, I think this is a reasonable approach. Personally I would not go the xPath route, but when you and your users are happy with it, it's the right way.
Thanks for your inputs. I do really value it.
What would be your approach with the use case, if we have to give the business users the option of configuring the mapping to the excel based on the source data.
Is there any other way, Appian provides other than this XPATH, XML strategy? I know JSONPATH would be another way, so that you eliminate XPATH.
But other then these 2, do you see any way that we are overseeing?
First, I try to understand what my users want to achieve using Excel, and discuss whether there is an alternative. For some use cases, Excel is THE tool users need. Most of the time, Excel is just the only tools users had, got used to, and don't want to let it go anymore.
Then, we could expose that data via an API, and let users import data directly into Excel.
Or go with Process HQ and just let users do their own reporting and dashboarding, including Excel export.