Discussion:
How to trigger a confirmation box from TDI v7.1.1?
(too old to reply)
Gaurav Sinha
2016-12-07 12:45:42 UTC
Permalink
Hi TDI'ers out there,

I have some assembly lines, which if mistakenly run at wrong time, can cause havoc. I would like to implement some logic that would trigger a confirmation box for the user to say yes or no, or something like that.

Is this even possible? If yes, any idea how this can be achieved?

I have not been able to implement windows.confirm() method because TDI doesn't recognize it.

Any help in this regard is appreciated.

Thanks and Regards,
Gaurav.
Eddie Hartman
2016-12-08 08:54:51 UTC
Permalink
Post by Gaurav Sinha
Hi TDI'ers out there,
I have some assembly lines, which if mistakenly run at wrong time, can cause havoc. I would like to implement some logic that would trigger a confirmation box for the user to say yes or no, or something like that.
Is this even possible? If yes, any idea how this can be achieved?
I have not been able to implement windows.confirm() method because TDI doesn't recognize it.
Any help in this regard is appreciated.
Thanks and Regards,
Gaurav.
Sorry, Gaurav, but TDI(SDI) does not have any native user input features that can be expoited in an AL. If you need a UI then you have to do something like providing an HTTP Server AL that serves up a web page. Note that the FDS (Federated Directory Server) app is just that: a single-page web app that drives the underlying TDI solution that does the actual synchronization work.

-Eddie
yn2000
2016-12-08 17:42:23 UTC
Permalink
Yes, it is true that "..TDI(SDI) does not have any native user input features that can be exploited in an AL..", but there are so many ways to trigger an on-off AL. I was implementing on-off AL by just detecting whether a file is existed in a directory. So, technically, we can use HTTP Server (like Eddie said), email, text in a file/properties, SNMP, SMS (I never try this, but I recall that there is a connector for SMS, right?), DB entry/flag, LDAP entry/flag, CLI that call procedure this or that, or any other (non-native) way to communicate with human.

Have fun. YN.
Eddie Hartman
2016-12-09 17:38:14 UTC
Permalink
Post by yn2000
Yes, it is true that "..TDI(SDI) does not have any native user input features that can be exploited in an AL..", but there are so many ways to trigger an on-off AL. I was implementing on-off AL by just detecting whether a file is existed in a directory. So, technically, we can use HTTP Server (like Eddie said), email, text in a file/properties, SNMP, SMS (I never try this, but I recall that there is a connector for SMS, right?), DB entry/flag, LDAP entry/flag, CLI that call procedure this or that, or any other (non-native) way to communicate with human.
Have fun. YN.
You are so right, YN. Thanks for clarifying this! As YN says, Gaurav, you can use all kinds of 'events' to trigger an AL. And, no, there is no SMS component - however, there are services you can make calls to. Of course, if you want an interactive UI then HTTP Server Connector-based AL is the most straightforward option. In truth, you can make your UI in any tool, as long as you can call out to your solution - for example, with an HTTP Server Connector that provides a simple REST service. Like in the YouTube video :D

-Eddie
Franzw
2016-12-12 11:58:08 UTC
Permalink
Post by Eddie Hartman
Post by yn2000
Yes, it is true that "..TDI(SDI) does not have any native user input features that can be exploited in an AL..", but there are so many ways to trigger an on-off AL. I was implementing on-off AL by just detecting whether a file is existed in a directory. So, technically, we can use HTTP Server (like Eddie said), email, text in a file/properties, SNMP, SMS (I never try this, but I recall that there is a connector for SMS, right?), DB entry/flag, LDAP entry/flag, CLI that call procedure this or that, or any other (non-native) way to communicate with human.
Have fun. YN.
You are so right, YN. Thanks for clarifying this! As YN says, Gaurav, you can use all kinds of 'events' to trigger an AL. And, no, there is no SMS component - however, there are services you can make calls to. Of course, if you want an interactive UI then HTTP Server Connector-based AL is the most straightforward option. In truth, you can make your UI in any tool, as long as you can call out to your solution - for example, with an HTTP Server Connector that provides a simple REST service. Like in the YouTube video :D
-Eddie
I will take a different shot at this....

From an architectural POV there is something very wrong if you need this kind of oversight. So I would recommend that you go back to the drawing paper and start thinking about to have the critical points "fail gracefully".

I know that this is easier said than done - but if you go into "automation" the assumption in enterprise architecture is that the data quality is the responsibility of the sending system - this is also called "garbage in - garbage out" principle. So following this principle every process should ponly send validated data down streams.

My recommendation is to apply the principle to your coding and eventually abort if something pops up (or just skip that entry/flow). This will much better in the long run.

HTH
Regards
Franz Wolfhagen
Gaurav Sinha
2016-12-14 06:43:39 UTC
Permalink
Hi Eddie / YN / Franz,

Thank you for your helpful guidance.

I have used a small vb script to prompt users when they are about to run an assembly line that could restart some appliances.

@Franz, totally agree with your concerns. But my support team uses some assembly lines on regular basis and sometimes they have so many of them open that they get mixed up and accidents happen. I am trying to provide just a stop gap solution so that some assembly lines are not run unintentionally.

In case my solution helps someone, following is the vb script I have used

Set objArgs = WScript.Arguments
messageText = objArgs(0) + " " + objArgs(1) + " " + objArgs(2) + "?"
result = MsgBox (messageText,4)
WScript.Echo result

and this is tightly tied with the following code snippet I have written in my assembly lines

var applName = work.getString("applName");
var fixPackLevel = work.getString("fixLevel");
var promptScript = system.getExternalProperty("promptScript");
var cmdStr = "cmd /c cscript " + promptScript + " \" Are you sure you want to install fixpack \"" + fixPackLevel + " on " + applName;
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","Are you sure you want to install fixpack " + fixPackLevel + " on " + applName + "?");
task.logmsg("INFO","***************************************************");
var cmd = system.shellCommand(cmdStr);
if (cmd.getOutputBuffer().contains("6")){
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","User clicked Yes when prompted, continuing with the assembly line");
task.logmsg("INFO","***************************************************");
} else if (cmd.getOutputBuffer().contains("7")){
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","User clicked No when prompted, aborting the assembly line");
task.logmsg("INFO","***************************************************");
system.abortAssemblyLine("User clicked No when prompted, aborting the assembly line");
}


I am a beginner with TDI, so am not suggesting that this is the only or the best way to trigger prompts. This is only my humble attempt and it works for me. I would be happy to discuss any improvement.
Gaurav Sinha
2016-12-14 06:51:49 UTC
Permalink
Hi Eddie / YN / Franz,

Thank you for your helpful guidance.

@Franz, totally agree with your concerns. But my support team uses some assembly lines on regular basis and sometimes they have so many of them open that they get mixed up and accidents happen. I am trying to provide just a stop gap solution so that some assembly lines are not run unintentionally.

I have used a small VB script to prompt users when they are about to run an assembly line that could restart some appliances.

In case my solution helps someone, following is the VB script I have used. I have placed this VB script in the solution directory and have named it messageBox.vbs

Set objArgs = WScript.Arguments
messageText = objArgs(0) + " " + objArgs(1) + " " + objArgs(2) + "?"
result = MsgBox (messageText,4)
WScript.Echo result

I have added a property with keyword promptScript and value messageBox.vbs to the project specific property file.

The VB script is tightly tied with the following code snippet I have written in my assembly lines

var applName = work.getString("applName");
var fixPackLevel = work.getString("fixLevel");
var promptScript = system.getExternalProperty("promptScript");
var cmdStr = "cmd /c cscript " + promptScript + " \" Are you sure you want to install fixpack \"" + fixPackLevel + " on " + applName;
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","Are you sure you want to install fixpack " + fixPackLevel + " on " + applName + "?");
task.logmsg("INFO","***************************************************");
var cmd = system.shellCommand(cmdStr);
if (cmd.getOutputBuffer().contains("6")){
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","User clicked Yes when prompted, continuing with the assembly line");
task.logmsg("INFO","***************************************************");
} else if (cmd.getOutputBuffer().contains("7")){
task.logmsg("INFO","***************************************************");
task.logmsg("INFO","User clicked No when prompted, aborting the assembly line");
task.logmsg("INFO","***************************************************");
system.abortAssemblyLine("User clicked No when prompted, aborting the assembly line");
}


I am a beginner at TDI, so am not suggesting that this is the only or the best way to trigger prompts. This is only my humble attempt and it works for me. I would be happy to discuss any improvement.
Gaurav Sinha
2016-12-14 07:01:31 UTC
Permalink
Just to add on to my previous post, the assembly line code has been written in "Before Init" hook, to ensure that this snippet gets executed before any other does.
g***@gmail.com
2016-12-20 00:01:19 UTC
Permalink
Turns out the system.shellCommand caches the user Id of the person who last restarted Default server on that system. And in doing so, prompts only that user, irrespective of whoever else tries to run the same assembly line.

If I restart the Default server and ask my colleague to run the assembly line, I can see the prompt on my machine, while his log console (which is waiting for my response) gives him no option to interact.

One way to get around this, would be to have a unique service for every employee in the team, but that will lead to a messy situation.

Trying to figure out any other way around this.

Loading...