Reference for [1] = Ice.Core;
Reference for [2] = System.Net
Reference for [3] = Unknown; but it works in the BPM nonetheless
All three approaches compile without error.
[1] does not return any value whatsoever.
[2] returns the Epicor server host name.
[3] returns the Epicor server host name.
Based on these results, my guess is that Data Directives actually process at the server (perhaps because it’s dealing specifically with the SQL platform at that point) and therefore, will not communicate directly with the client (making my requirement to latch on to the client workstation ID an impossibility).
Might any of you have a different approach to this? Has anyone successfully bridged this gap before?
I did a quick test in a client customization by attempting to place “Session.WorkstationID” into a form label (the result was a completely blank label) versus placing “Session.UserName” into the same form label (which successfully returned my Epicor user name).
My guess is that “Session.WorkstationID” is a mere leprechaun - perhaps a session object that has been retired?
My understanding of workstations (and I will say upfront I’ve never ever looked at configuring this functionality) is that you have to “select” which workstation you want to use. The workstation ties together printer, attached scanner etc.
If you’ve not selected a workstation, then the ID being blank would be correct. Can you confirm you’ve selected/assigned a workstation?
I concur with @markdamen. If you havent selected a default workstation (or manually selected one from the main screen), it will be blank.
However - you are correct, BPMs run in server context. If you need that data (Workstation, etc), you can pass it in callContextBpmData
//in form before call to method
var WS = ((Ice.Core.Session)oTrans.Session).WorkstationID;
var edvBPM = oTrans.Factory["CallContextBpmData"];
edvBPM.dataView[edvBPM.Row]["Character01"] = WS;
//in BPM
string WorkStation = callContextBpmData.Character01;
@markdamen - Looks like our Epicor configuration has no workstation records built. To be honest, I don’t know what the workstation records might be used for (what the benefit of creating and maintaining them might be). I’ll have to see if there’s a workstation topic in any of the Epicor documentation I have and do some reading.
@Chris_Conn - I’ll try the CallContextBpmData approach today and will let you know if I have any success there – thanks for giving me a nice example to build upon.
@danbedwards - I tried the “ClientComputerName” property this morning and it appears that I’m not using an assembly reference that might be required. Here’s the error I’m receiving when launching the customization:
Error: CS1061 - line 40 (303) - 'Ice.Core.Session' does not contain
a definition for 'ClientComputerName' and no extension method
'ClientComputerName' accepting a first argument of type
'Ice.Core.Session' could be found (are you missing a using directive
or an assembly reference?)
We’ve considered that, but we thought of the possibility that the user might wander to another PC. So, we’d need to know which PC is being used at the time data entry is occurring.
To offer some details here, this ties in with the other recent question I had for you on the “Multiple Wireless Label Printers” thread. Our preliminary thinking is, if we can understand where the user is, we can build the logic within the BPM to direct the label print output over to the correct DYMO printer at that exact PC location where the user is sitting.
@Chris_Conn - I did want to mention that, even though my implementation is for a Standard Data Directive BPM (that calls an auto-print using a BarTender label template), it is being triggered on this condition:
I understand that this is all server-side processing.
However, the recent test I did just to try to pull in the “Session.WorkstationID” variable, which did not work, was performed directly on a client form:
So, I believe your earlier support of @markdamen’s explanation makes sense to me - because we have no Workstation records configured in the Epicor application.
Sounds like what I really need is to pull in, perhaps, a WMI call for the client host name, and store that into a container within the BPM? (Just making a wild stab with a dull knife…)
@danbedwards - Dude… (if I may be so informal…) that worked!
Now on to to second part of this effort - which is to use the host name to direct the auto-print output to the right DYMO device. I’ll post back here in a few days to let you guys know if I’m successful (but something tells me I’m just going to start a new thread with more questions as I go further along… )
I wanted to test this for myself, ran the debugger, and WorkStationID has no value !!!
And I did not see this as a parameter in the config file, local to the computer…
Chris, I tried your code but was getting a compilation error at
var edvBPM = oTrans.Factory["CallContextBpmData"];
(Impossible to apply indexation with [] to an expression of type “group of methods”…)
Modified it as:
But in the Method directive, Trying to show callContextBpmData in a message…no info was shown. as if empty.
I finaly used the following in my customization, adding Environment.MachineName, and added to a context menu row.;
oTrans_ordAdapter.BpmContext = new ContextDataSet();
var row = oTrans_ordAdapter.BpmContext.BpmData.NewRow();
row["SysRowID"] = Guid.Empty;
row["Character01"] = Environment.MachineName;
row["Character02"] = (Ice.Core.Session)oTrans.Session.TaskClientID.ToString() ;
oTrans_ordAdapter.BpmContext.BpmData.Rows.Add(row);
I have two questions:
If I use the first method, nothing shows via the callcontext variables…as if this data is not passed to the bpm’s…
Using the second method, if I read the callContextBpmData in the Update method directive, I have access to the variables info.
BUT If I show the same info at the data directive level… the callContextBpmData info seems empty!!!
I would have expected that the info would follow through till the end?
Since this is not working how do I pass callcontextdata from my form to a data directive then?
Thanks.
PS: I do not see ClientComputerName in the ClientContext fields available… Is this only available in the newer versions? (I am on 10.0.700)
I see you were after the Computer Name… We’ll for your 2nd part add an AutoPrint and then inspect the code that Epicor Generates for more Printer related samples
Thanks for the code sample, as well. This appears to be precisely what I’m envisioning. I’ll see what I can do with the direction you have provided here and will respond back to the thread when I have some progress (might take a few weeks because I start vacation tomorrow).
@Chris_Conn - I did follow your “callContextBpmData” example to store the DYMO printer name I isolated; and from that, I was able to pull it back to the BPM. So, thanks very much for presenting that option.
I think I have isolated the autoprint code that I’ll need to pull this off, but when I save the custom code block, I receive an error concerning assembly references:
Server Side Exception
There is at least one compilation error.
Exception caught in: Epicor.ServiceModel
Error Detail
============
Description: There is at least one compilation error.
Details:
Error CS0234: The type or namespace name 'Tablesets' does not exist in the namespace 'Erp' (are you missing an assembly reference?) [PostTran.Q.RcvDtl.Receive.cs(155,29)]
Error CS0234: The type or namespace name 'Tablesets' does not exist in the namespace 'Erp' (are you missing an assembly reference?) [PostTran.Q.RcvDtl.Receive.cs(156,30)]
What assembly is required for that “Tablesets” reference?
An interesting note here is that, if I tack on an “Auto Print” BPM block directly after this custom code block (there’s no specifically logical reason for doing that – I merely wanted to save that block in case I needed to get back to it - and - I fully expected the BPM to execute 2 print jobs [one for the custom code block and one for the auto-print block]), the BPM saves without error and executes 2 print jobs for the number of labels designated in the “Labels” textbox. If I remove the auto-print block, the BPM fails on save with the aforementioned error.
)
