I have started using Epicor Functions and I have a question regarding the variable “types”.
How can I make a variable with a plain “DataTable” type (or similar)? I see all the primitives types (int, decimal, boolean, etc) available via the drop down. I also see a DataSet type which is almost what I want. I also see how to access types from various services and assemblies. The problem is, when I use the “Fill Table By Query” block, I need to be able to store the results somewhere (like a plain DataTable) so that I can consume it from the next C# custom code block where I implement some custom logic. It seems the block won’t allow me to create a table on a DataSet variable. The only choices are tables with “TableSet”-like types provided by services or assemblies.
My exact application is:
Pull some columns from the JobPart, Part, and PartClass tables via “Fill Table By Query”. (This returns only one row selected by JobNum)
Access row[0] and perform some custom logic in C# custom code block
Set outputs according to above logic in C# custom code block
I am talking about variables within a function, but it seemed like the options are the same for both? Being able to set the data to one of the output variables would probably work for my application as well.
When you invoke a BO, you have the option to set the output to a local variable, which is what I think you’re needing. This will be of the tableset data type associated with that BO
Then, this local variable is acted on through the life of the BPM execution. For example, I invoked Get By ID with my BO execute node, then I have a conditional block to look at the value of the local tsUD100 variable
Each BO method calls .GetByID and stores the data to the appropriate Tableset created just as you showed in your post. However, when I run just the flow above, the execution time (via the REST API) is about 10 seconds (the custom code block is only a few lines, mostly setting the outputs). This is about half of the full function and the full function runs in 18 seconds. This function is being accessed by an automated system (a packaging system, loads info to be printed on a sealed bag), and the 20s load time slows down the cycle (one system packages a variety of product). My attempts with the “set table by query” block was driven by a hope that it would reduce the time. Maybe I was attempting to misuse that block.
I’m getting away from the original topic, but does 10 seconds seem reasonable for accessing those three BOs?
When I click (1) the “Select Table” dialog pops up. My desire was to be able to “create a variable” for the drop-down (2). Currently, the drop down is populated by the variables I made for that first flow, but a variable of type “DataSet” (created in the Variables tab) is not present. There is also no option to create a new table as with the Invoke BO Method blocks.
Hard to say exactly, but I know the Job BO is a hefty one. That could probably be trimmed down via a BAQ call like Mark suggested. The other thing I know is that when I publish a function and then call it for the first time, regardless of the function contents, it seems to take a while to return a response. Subsequent calls are much faster, so I am not sure if there is some sort of build process required the first time a published function is called. @Olga?
Yea, I think I’ll go down that path by compressing those three calls to a BAQ and calling it as described in Mark’s linked post. In fact, later in this same function I call three other BAQs (the post you linked was actually my original reference on how to do that, thanks!)
Aaron - Interesting observation, that may have been the case with that 18s benchmark I mentioned. Running it several more times, the entire function is averaging around 8-9 seconds. That’s much more acceptable to my application, and if I squeeze out a couple seconds with the BAQ I will be in very good shape!
