pub.string:substitutePipelineVariables doesn’t retrieve value inside array variable or inside Document List, to be Replaces a pipeline variable with its corresponding value.
Error messages / full error message screenshot / log file:
it works fine when i use “perform pipeline variable substitution” .
But when i use pub.string:substitutePipelineVariables, and use the same pattern '%data[1]/Alamat%’ i didn’t retrieve value as what i expected .
i need help, how to perform pipeline variable substitution inside array datas (document list) using this WMPublic services (pub.string:substitutePipelineVariables) ?
Question related to a free trial, or to a production (customer) instance?
can you describe your issue more detailed, please?
Please provide the 3 screens in 3 independent screenshots as this will make it easier to analyze them.
The provided screenshot and text does not provide enough information to help you.
Might consider using a different map technique. We follow a guideline of “prefer direct map over var substitution” because var substitution is less readable and maintainable – not in a really significant way but it is a bit more involved than direct mapping.
Seems a bit odd to use variable substitution from an array.
Can you please describe the requirement from a business perspective as much as possible? I intentionally did not say “business requirement”, but try to go away as much as possible from the approach you have tried so far.
It could e.g. be that you need to extract a certain field from the second entry in the list. In that case there are other options, in Flow as well as via a Java service.
The needs is i want to make general services that can support parameterizing mapping via databases. To achieve that i try to implement the concept of subtitute pipeline variable. so if i want to mapping payload into an some destination i just need declare in databases as json in databases which the value of the key it would be %value/path/from%
The concept of perform pipeline variable substitution and pub.string:subtitutePipelineVariables should be same right?
but i find bug in pub.string:subtitutePipelineVariables (webMethods 10.11) that they have different behavior with perform pipeline variable substitution. i can’t retrieve value as what i expected (in this case from array)
But finally I was able to solve it because this bug already fixed in webMethods 10.15 , thankyou! even when the index is not found it will retrun error (java.lang.ArrayIndexOutOfBoundsException)
Although it already solved, i want to hear from your perspective about the needs that i’m currently working (general services that can support parameterizing mapping via databases) and the concept of subtitute pipeline variable that i try to implement. in case you might have any suggest or advice ? Thankyou
For my current client, I had to build a framework to enable our developers to create dynamic queries for inbound objects so they could pull data out of different documents in a configurable manner. I can elaborate more if needed, but the point of the story is: initially, the framework supported using the webMethods variable substitution syntax but I found it to be fairly limited, so eventually, we created a utility package that allowed us to perform JMESPath queries against the inbound IS document (https://jmespath.org/). It is more flexible and powerful. Plus, our team was already using JMESPath in other parts of our platform, so it was an easy transition for the team.
It sounds like your requirement may be similar (i.e. you want to store these configurable “queries” in a repository and apply them at run-time to the pipeline), so perhaps consider using something that will give you a little more flexbility. JMESPath is just one example.
By this you don’t mean you are trying to implement a graphql service are you? It is not clear to me either unfortunately. But to me it sounds like you are using the wrong tool or methodology. A screen shot and/or better description of the requirements would be great.
And I agree a bit with what @Percio_Castro1 posted regarding being configuration driven when appropriate.
The concern I would add – is this dynamic, configuration-driven approach where field mapping is externalized a compelling benefit? It’s something to consider because what is being done is moving the “development” elsewhere where there is less control, less debugging available, etc. “Service XYZ failed – was it due to bad configuration for a mapping? If so, which one?” Or another case: “this var name changed – is there a number of config records that need to be updated and retested?”
The appeal and benefit of frameworks to help simplify future work is obvious. We’ve all done them. Just make sure that it adds benefit and is not simply moving the same work elsewhere with additional challenges that negate the benefits.
