Dynamic default value static lookup
Hello,
Today I ran into a situation that I'm not sure if it is possible to handle with static lookup.
I am trying to map one field to another, but knowingly am only mapping some of the most common values. Ideally, I would like only these values to be processed by the lookup, and then the others mapped directly (there would be several more options in the actual production instance):
This simply prints the "$.shipping_method" literal without parsing the field value.
Is there any way to use actual handlebar expressions as the output of a static lookup?
0
Comments
Update - I can identify one possible workaround as using a series of nested #compare statements. This is doable, but not really ideal given the number of options I have.
Ezriah I would suggest having all options put in the static list. If you have tons of options, you could quickly add them all via api. Check out this post: https://docs.celigo.com/hc/en-us/community/posts/360071519412-HOW-TO-What-s-the-best-way-to-load-a-static-lookup-with-a-lot-of-items.
Tyler Lamparter Thanks for this idea.
In this case, the issue is that there are arbitrary unknown values that this field could potentially have.
Ideally, there would be a way to use a dynamic custom value for a static lookup default value, rather than just a static value. The expected outcome of the mapping is that any of the listed values are explicitly mapped as given, and any other values are simply passed through without change.
Ezriah I'd say it's not particularly recommended to have a quasi-enum field. Let's say you get a new shipping method in, but then later decide you'd actually like it to be renamed in a uniform way. You'd update your static mapping and then end up with historical data not matching new data unless you also back update old data. However, I'm also not one to deny someone for wanting to do what they'd like for their own business. I'll send this over to our product manager that owns mapper and log it as a potential future enhancement. In the meantime, you can use the handlebar statements or use a preMap script.
In the future, we will be introducing global cache/lookup tables and those will have handlebar support in the second phase. Once that's available, sometime next year, you could have a handlebar statement to get a value from cache with a given key and then if no results are returned you return the field itself.
Tyler Lamparter I understand your point and agree that it's not ideal. This was more a requirement of the destination system (if the shipping method was in its recognized list, it would build a tracking link, otherwise, it would be pushed as a custom value). Thanks for submitting the idea as an enhancement. From what I've heard of the lookup tables, I can't wait. We currently have four static lookups with identical mappings that all need to be adjusted whenever there is a change . . . having them all sourced from the same place will be amazing.
Please sign in to leave a comment.