Hi community,
I am wondering how the following use case will affect recourses and/or if there is a better way to approach it.I have to fetch several date from a JSON respons where the data I need is stored in multiple and long JSON paths, some 8 levels deep.there is some kind of root path to begin with that starts with the local variable that contains the total respons.
e.g. local!totalRespons.result.body.serverInfo (root path)
then refer to this root using a local variable named local!root.
then the response has two main "branches" person and company.
So I could make two variable local!person: local!root.person. and local!company: local!root.company.
I can continue to define the local variables this way multiple levels deep.
This way in my opinion the code is easy to read and is easer to fetch data using short paths, same reason for using dot notation opposed to using index .But in this approach all this variables depend upon each other but the values all depend on the initial response and no data is altered.
I could also define a variable for every field of data I need by define that variable using the full path.e.g. local!companyEmail: local!totalRespons.result.body.serverInfo.company.contactInfo.item.email.In total I have to fetch and store data in 15 variables. The expression that calls the Api with the response will be called about 250 times one by one looped in the process model.
What approach would you recommend?
Kind Regards,
Erik
Discussion posts and replies are publicly visible
I think that multiple lines like
local!companyEmail: local!totalRespons.result.body.serverInfo.company.contactInfo.item.email
are super readable.
What do you then do with these values? Why create a local for each? I assume you want to transfer them into your own CDT. Then you can do this
type!YourCDT( companyEmail: local!totalRespons.result.body.serverInfo.company.contactInfo.item.email, . . . )
Thanks Stefan,
Your assumption is right, the values will be used in a CDT.I started with separate variable's to individually check the responses fist, also for the majority of fields I also have to "filter" using for each to get the right value(s) out of the array. Now that I am able to correctly fetch the data along with your answer to my question, I will indeed initialize the CDT with the values by dot notation full path for each field in the CDT and then wrap them like this to handle null values.
companyEmail: index(local!totalRespons.result.body.serverInfo.company.contactInfo.item"email", null),
Or is this not a good thing to do?
index() will help you to catch the case that field does not exist at all. If you know that all the fields are always available, just go with the dot-notation.
Thank you Stefan, I will keep that in mind.