This is more of a concept question than an actual issue. Recently Intacct released a new query method to replace their old. They have not given a date on if/when the old will be deprecated but i am trying to be ahead of the game and get the new functionality in place.
For the old way, there was a simple “read” or “readbyquery” with simple object, fields, and query fields (image right). Now they are replacing it with a fuller expanded query function that separate each field, query, and all logic. (image left)
In apiant building a generic query assembly to handle any readby query was easy. couple of text entry parameters and go
Great.
Now with the new query, it is not so simple. each field will need its own node (or null if you want all fields) and filters being much more complex.
So with this I am trying to think of a viable way to make a generic module to handle queries now and more importantly, how to enter them. Im just not seeing anything within apiant so far to get where i want to be.
There’s nothing APIANT-specific about engineering backwards compatibility, which I assume is your goal. If anything, the ability to have a subassembly in our system has made it very clear and rather safe to make the needed changes and retain backwards compatibility with the overall integration. As long as the black box keeps its external input/output signature the same you can be assured of backwards compatibility. But sometimes backwards compatibility is either not easy to achieve or infeasible depending on what has changed with the processing requirements within the black box.
To achieve backwards compatibility, you leave that subassembly’s parameters in the screenshot alone. For the “Fields” and “Query” input values, you need custom Java code in the subassembly to parse their values and construct the needed XML to make the new API call. That’s it in a nutshell.
Building up the new XML via Java is more involved than probably what existed before, but shouldn’t be overly hard, depending on existing queries. You will need to account for all the existing possible queries the integration currently makes. All the existing queries will determine how hard it will be to build a parser for the translation. If they all just do “=” equivalency tests, that is easy. If they use complex expressions of arbitrary complexity, then that is rather hopeless. In that case, I would consider how many of those complex expressions exist vs. the easy ones. Maybe it would make sense to do a hybrid approach, where the modified subassembly handles a high percentage of the cases and then you retool the remaining cases with basically a custom approach for each, e.g. you hardcode the needed XML expression query in those places.
I don’t see how this would be different for any other integration tool. The subassembly is providing an abstraction to wrap an API call. There’s no easy way to abstract out a similar re-usable module with an expression engine that can create that new XML structure for queries of arbitrary complexity.
sorry, I should have been more clear about what i was trying to achieve.
I do not think building it out in general would be too difficult. the logic behind how it functions is not a problem. Im actually not even really concerned about backwards compatibility that much. What im trying to find is a good way to wrap it cleanly so i can reuse it and dynamically add inputs.
for example…
Whether I want to use a single line on the filter or a dozen, I need to be able to easily input that in the subassembly. so I would need some way to add a new set field:value pairs for each filter. What would be the best way to handle that without prebuilding a giant table to handle up to a dozen? I guess what i am looking for is a way to utilize something similar to the filter rows function on triggers.
something similar to this would allow me to add filters as needed, maybe replace the “condition” with my known values for my own filters. Is something like that available to use?
Um, no. I thought you needed a UI control for actions in automations.
Not all Parameter modules are currently supported in subassemblies. I haven’t had time to build them all and to date nobody has needed them.
Even so, you would still have work to do to translate its inputs into that XML syntax.
So why not just accept the new XML syntax directly as input? Can use the Scrolled Text Entry parameter module to accept a long text value.
As you can tell, I can’t engineer a solution for something I have no idea how you intend to use. Nor will the system have an ideal solution for such a specific thing you are seemingly wanting to do. It would be possible to build such a specific solution into the system, but that always takes time and money.
Or talk to Intacct and explain why defining an expression language in XML schema is such a boneheaded idea to begin with.
you would be able to enter the object (or i could set it up to pull from an availble list, easy enough)
then you could keep adding fields
Then you could add filters, ands/ors, group them, etc.
That would be 100% perfect. then i could handle all the logic within the assembly to build the query and it would be reusable as a user to put that in other assemblies easily.
I just dont know how to get there. If I cannot get there, sure i could just use text entry and build out the xml manually though. i just think if i can get this part built then it would save countless hours in the future from hand building out the query each time
That level of customized UI is not currently possible with Subassemblies and won’t be possible for a long time to come.
For an immediate solution you will need to use something like the Scrolled Text Entry parameter module and decide what sort of textual schema to use to define queries for the Intacct XML, either pass in the XML verbatim as needed to make the API call, or parse the text and convert into the final XML.
ok thanks. If/when that type of customization is available (or even ready to test) please let me know. I have a few ideas for things that would be great to try on that.
So basically you could build that fancy UI you sketched out (more or less, some things won’t be possible) and then implement the logic to make the Intacct API call all within the custom module.
Modules can be edited in two ways, one is via the gear icon in their title bar, the other way is to right click on them in the catalog and choose the Edit option.
But I see your system is currently not licensed for the Module IDE, so I have teased you with forbidden fruit.
You will need to contact Frederic to inquire about gaining access to module development, if interested.
We have some documentation about the Module IDE. The underlying Module API is not documented but its source code is viewable from the IDE. It is best learned by studying existing module implementations. It’s not too hard, especially since there are so many modules to copy/paste code from.
Module development involves first writing and testing the module in the assembly editor using JavaScript syntax, then porting the code to Java and testing for server-side execution in automations. The porting is usually easy, just change JavaScript “var” variable declarations to Java types like String, int, etc.
You can probably get by with using subassemblies as they are today, but it won’t be nearly as pleasant solution as achievable with a custom module. Plus you may find other situations where knowing how to build custom modules is better. One big advantage of custom modules is that they offer the highest possible performance, especially when working with large XML documents, vs inline JSP script. Inline JSP has to be compiled on-the-fly and its input XML inserted into the code before compilation.
