You are viewing limited content. For full access, please sign in.

Question

Question

Trouble using the Dymo SDK with Workflow - SDK works, but fully tested input methods produce different output than expected

asked on September 21, 2018

I was able to successfully install the Dymo SDK and call a print job from the workflow designer using the script activity and C# (Using the play button in the script editor). However when the workflow runs, the Dymo prints a full black label instead of the label it was instructed to print. The code did not change, so some external hidden influence must be involved.

So I installed Visual Studio, wrote a C# console application, entered the same SDK code. Then I wrote code in the workflow script activity to execute the console application. I click play in the script editor, it prints the label. I run the workflow, and nothing happens. The output string from my command execution is also just blank. Some external influence seems to be preventing me from using this SDK.

I read all the posts regarding not being able to print unattended, but I think this applies to calling a print job through windows, not through the manufactures SDK. I am able to print. The image is just full inked black instead of what it was instructed to print. I am lost as to why the same method, given the same input, is producing two different outputs (All Black Ink vs First Name, Last name, Company Name). This is unusual for a computer program unless there are inputs being made by a system out of my reach.

Here is the code I am using to run my Visual Studio made application as a work around. Again, this code also works perfectly when run in the designer, but from the workflow produces a different output (Nothing).

System.Diagnostics.Process pProcess = new System.Diagnostics.Process();
pProcess.StartInfo.FileName = @"C:\Dymo\CustomPrintProgram.exe";
pProcess.StartInfo.Arguments = first + " " + last + " " + company; //argument
pProcess.StartInfo.UseShellExecute = false;
pProcess.StartInfo.RedirectStandardOutput = true;
pProcess.StartInfo.WindowStyle = System.Diagnostics.ProcessWindowStyle.Hidden;
pProcess.StartInfo.CreateNoWindow = true; //not diplay a windows
pProcess.Start();
string output = pProcess.StandardOutput.ReadToEnd(); //The output result
pProcess.WaitForExit();
SetToken("Out",output);

 

0 0

Replies

replied on September 23, 2018

Chad,

My first guess is a difference in the AD account that the Designer is running under vs the account that the Workflow service is running under.  Why that would cause the symptoms you describe I can't say but it does not surprise me. 

Look at the Workflow service and see which account it is running under.  If it is not a production environment and you have some latitude then set the Workflow service account to use the same AD account you are logging into the server with to run the Designer, stop and restart the Workflow service and see if that makes a difference.

 

0 0
replied on September 24, 2018 Show version history

Edit: Opps responded to the work post.

I can give this a try, I can't leave it this way though. I don't want workflow to be dependent on my account or the active directory controller.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.