Inspired by @timshuwy, I’ve been trying to reduce network traffic of PCLookup routines. I’m able to read an entire lookup table into a .Net DataTable and then use Newton Soft to convert it to JSON. I get the whole string back and it’s beautiful. Now I want to deserialized it back into a DataTable for faster access locally but the Add References button is grayed out. The NewtonSoft DLLs are on the client but there’s not way to access them. Bug or reduced capability by design?
Thanks!!!
Mark W.
Another approach would be to put the data in PcCon Data or a UD table and bring back whatever
you need in a datatable via BAQ. Works on client side configurator method, MT SaaS.
Whatever approach you take you will probably feel a little cramped by the lack of classes/global variables. Even if you bring in the whole table, its hard to cache without a persistent place to store the data. I just de-serialized to text in a text box input and parse it again later when I need it, but that isn’t great either.
One of my configurators got so complex I took it out of Epicor and just assign materials and operations via REST instead - development has gotten so much easier I am considering taking them all out and giving up on the built in configurators.
Oh my yes. When I saw the “Local Variables” capability, I was hoping that these were variables available to all routines. But alas…
Deserializing on demand is not convenient but it will certainly be faster than all of those PCLookup calls from Europe/Asia! 
Yea, JSON works only for server side…
BUT all is not lost… you can build your own comma delimited table on a server side, stuff it into an Editor input, and then parse it back out into a table whenever you need to use it. This does significant reduction in traffic for doing any data lookup, because everything can now be local.
the JSON work That I have been doing is more about communicating between the Configurator and Sales Order… we build up a JSON, and push it into a UD Field on the sales order which then can be used for to do additional work. We have a BPM that fires in the sales order, the BPM parses out the JSON and makes additional decisions.
Since I’m doing a DataTable, I should be able to do the standard WriteXML and GetXML on the client to get back to the DataTable. The XML is more verbose. Most of our tables are not that big but I want to avoid having to mange chunks in multiple Inputs though…
Still noodling this one…
I WAS trying to do this first by returning an array of strings where the first was the header and the remaining lines as data records but since 10.1.500, the ability to pass or return an array of strings causes a stack overflow and do date has been set to fix it. We may want to remove that option (string) until that gets fixed…
I did not read the whole thread but are you referring to passing an array to UD method and back? This works … simple example (maybe not what you are referring too tho 
)
// Used in Button Click
string[] InputArray = new string[10];
string[] RetValue = new string[10];
InputArray[0] = "Value1";
InputArray[1] = "Value2";
RetValue = UDMethods.TestArray(ref InputArray);
MessageBox.Show(RetValue[0]);
MessageBox.Show(RetValue[1]);
// UD Method
// Enter valid C# code and do not forget this method returns a string value.
// ref for UD method is InputArray string[]
// Return type is string[]
string[] RetValue = new string[10];
string pInputValue1 = InputArray[0];
string pInputValue2 = InputArray[1];
RetValue[0] = pInputValue1 + "-Ret";
RetValue[1] = pInputValue2 + "-Ret";
return RetValue;Here is a section of code that will turn a delimited edit field into a table which can then be used client side… of course, every time you want to use it, you need to recreate this table, but these few lines of code run really quickly (assuming you already have the comma delimited data.
In this example, i have 9 columns of strings. delimited with ~ between each line, and a back tick between each field… example:
rowa1`rowa2`rowa3`rowa4`rowa5`rowa6`rowa7~rowb1`rowb2`rowb3`rowb4`rowb5`rowb6`rowa7~rowc1`rowc2`rowc3`rowc4`rowc5`rowc6`rowc7
Here is sample code
System.Data.DataTable dt = new System.Data.DataTable();
dt.Columns.Add("Question", typeof(string));
dt.Columns.Add("Answer", typeof(string));
dt.Columns.Add("Description", typeof(string));
dt.Columns.Add("Sort", typeof(string));
dt.Columns.Add("Filter", typeof(string));
dt.Columns.Add("Filter2", typeof(string));
dt.Columns.Add("SecurityRole", typeof(string));
dt.Columns.Add("FastShip", typeof(string));
dt.Columns.Add("ImageFile", typeof(string));
/*Here we split up all the data into separate lines*/
string[] lineArr= Inputs.TableData_Edt.Value.Split('~');
/*Now, we take each line and load it into an array*/
foreach (string line in lineArr)
{
string[] lineData = line.Split('`');
dt.LoadDataRow(lineData,true);
}Fixed length arrays may work but what I was trying to do (at first) was return an array of strings of unknown length. This causes a stack overflow. It’s a known issue.
4/5/2016 Linked call 1772357PSC reporting the application crashing using string arrays in UD Methods.
PROBLEM :
User defined methods offer a return type of string (string array) and a parameter type of string. There is no logic to support a string array parameter. When a string is used for a return type, a stack overflow condition occurs causing E10 to shut down.EXPECTED BEHAVIOR:
The stack overflow should not happen and the array defined should be returned to the character field.
This may need to be enhanced to handle an array return type.WORKAROUND:
Use String return type.
This is considered an enhancement request at this time with no target date.
So, there are two situations we are dealing with here: the speed of PCLookupData routines and Internationalization. The DataTable is definitely a speed improvement but there’s an issue when passing decimals (and probably dates) using delimited strings when the server is using one culture setting (e.g. en-us) and the client has a different culture setting (e.g. en-uk or de-de…). A decimal string “1,000.00” returned to a US client yields 1000 in a ParseDecimal routine but the same string will error out in Europe. A decimal string of “1.0” will produce 1 in the US but 1000 in Europe. I was testing to see if the deserialization of NewtonSoft or GetXML would save me the trouble of manually handling the conversion.
The trouble I was having is that the user’s culture setting is not directly known to the configurator client. However, I think I’m going to use a web technique and infer the culture setting with a client-side test to see what results I get when passing in different values and then create my own ParseDecimal/ParseDate routines. I’d like it to work in the standard product but the US-centric developers have been slow to recognize the issue.
Thanks!!!
Mark W.