How can I feed an array value to a connector function as a filter input?
I have successfully managed to do it manually by specifying an array-like string. But in this particular use case I need to use an array value which is retrieved from another connector function.
This is all using the Tulip table API.
Using the TOTEXT() function will escape the resulting output string… What else can I do to get the true array returned?
Hi @sebme, let me see if I understand this correctly:
You’d like to use the value of the variable target_material_list—which is itself an array value returned by a connector function—to act as a filter for a second connector function. The place you’re struggling is that connector functions return arrays, and you cannot pass an array into an input field for a connector function. So you’re in a situation where you need to convert the array to type TEXT so that the ISIN filter will function.
Hi John, yes, your understanding would be correct.
In the meantime I found a workaround solution either through a custom widget which does the required pre-parsing or - what our implementation partner suggested - going by concatenating the array and feeding it into a partially completed array string…
Neither workaround is particular pretty, so it would be really helpful if in the near future one would be able to directly feed arrays into the “isIn” (or “notIn”) filter.
Hi @sebme, glad you were able to find a work around in the interim.
I just checked in with the team that manages connectors, and they’re working on building functionality that will allow you to pass arrays and objects into connectors. I’ll be sure to post back as this work progresses.
Hi @bharatreddyv, thanks for bumping this. I just checked with the product team in charge of this feature update. It is being tracked in our backlog but unfortunately I don’t have a date to share for when we expect this work to be completed.
Our process requires running through multiple lines within a transaction, collecting all of this data and returning one communication to our ERP system the results of these transactions. The Tulip limitation of allowing only 1 transaction in an array value at a time to be processed has caused issues with our business process. We have been working with Tulip Professional Services and have hit roadblock. Trying to get this request moved in priority if possible.
I can speak to this gap a little more (and why it still exists). This is the area of the product I own.
We have been apprehensive to implement support for arrays as a connector input for fear that customers will start using single connector function calls to do batch operations. This creates a few tricky states to handle:
If I send 1 connector function to update 4 separate orders, what do I do if 1 of the 4 fails? Do I continue to the other 3?
If 1 of the 4 fails, what response code do I return?
Support for Restful APIs to do these sorts of batch operations is on the edges of best practice and something we want to protect users against attempting.
The challenge here comes with the detection of users making this mistake, and guiding them to best practices (which would be splitting these sorts of batch updates into separate calls). Generally, this would be indicated with lists being used in the payload of a POST or UPDATE call, but there are very valid cases where you would need array access but aren’t doing batched operations (like adding a line item to a single order, on order creation).
These challenges aren’t insurmountable, and we could just ship this functionality without any sort of warnings for risky behavior, it is just something we need to implement carefully.
Thanks for continuing to bump this thread, it triggers further internal discussion that ultimately drives prioritization around taking another look at this ask.
in my opinion Tulip should not try to guard against all sorts of edge cases. After all, there is some skill required to make use of these connector calls.
It is extremely frustrating to be artificially limited in a basic (depending on perspective maybe slightly advanced) operation just because there is the hope to guard against any DAU.
