Hello - We have 5 lines mapped, and when we placed our calls for testing, we found that 3 out of 5 tried to process the same call, even though the database status (which indicates call status) indicates that the call should not be attempted once the value is set. It LOOKS like instead of an instance of TeleFlow per line that the application is actually shared so certain variables are picked up by the others. Is there a setting somewhere that forces each TAP to be isolated and use its own resources?

Thanks in advance,
Susan

Each application instance doesn't share information with each other instance. Only through application design can communication between instances be achieved, which would have to be done with something external to TeleFlow(Eg. a database).

I suspect what is happening is that multiple applications are actually requesting the information at almost the EXACT same time.

If the basics of you application are as follows, you will invariably have some jobs picked up by multiple ports:
-- Application starts, checks for a task where call_status = "INCOMPLETE"
-- Application updates call_status to "CALLING"

The reason being, there is nothing in what I just described to stop two or more processes from running the first check at the same time. It is possible, as well, that one runs slightly behind the other, and the update to call_status doesn't happen before the second application instance gets the task. This all happens in milliseconds, I'm sure, but they will still bump into each other.

The "quick fix" if you are doing something like the above:
1) Add a port field to the task table, make its default value 0.
2) Making some assumptions about how this table "looks", your update query might look much like this:

3) After the update, only place an outbound call if this query gets a row:

4) Be sure the application updates the call_status to something other than CALLING when complete.

Obviously, I'm making a great many assumptions about your application, but it seems to fit the problem.

The quick fix I describe isn't necessarily an ideal system, as it means the ports are in some respects "battling each other" for tasks. It is just a quick fix based on what I suspect is happening from your description.

Ideally, you might want to consider having ports "register themselves" as available in your database when they are idle, and having another process provide them with tasks to do, perhaps by assigning them a phone number and a call status of "PENDING" or some such thing.

You are correct about this happening at the same time. We are using an external database structure to keep track of calls (although we aren't tracking the port itself), and when we first bring the system up, there is a mad dash to process what's in the table. I really am not sure that adding port information would help, as we'd still have the simultaneous query issue, and our queries are already structured similarly so as to prevent a conflict. We feel that once calls get going, each TAP would be 'staggered' anyway since calls will have different lengths. But it's the initial poll that is causing the problem. Is there any way to set them to run one behind the other, by maybe a 1 sec, to prevent this? I really don't want to have a completely different TAP for each line, only to add a different wait timer at the very beginning....

Thanks for your response, Chris,
Susan

Well, the "magic" is in the update and extra follow-up query to see if it was the current port that managed to do the update, or a different one. The updates are queued, so only one port could do the update. The second update (for the second port) would fail, because the status would have switched from INCOMPLETE to CALLING, for example.

If you'd prefer to depend on the staggering (knowing that every now and then, this will cause two or more ports to call the same number), just use a Wait step. Immediately after the very first START step in your application, have a Math step that multiplies 50 * @PORT into @PORT_WAIT. Then, use @PORT_WAIT in a Wait step. (So, port 1 waits 50ms, port 2 waits 100ms, and so on)

You might get away with smaller staggers, or you might find that they need to be longer, but that should about do the trick.

We'll try both, Chris. I hadn't thought of using the Math step, and that sounds the most promising. I suspect that we'll really only have this problem now, when then system is coming together to make its first calls, and probably after a service restart or system reboot.

Thanks a lot for your help - I'll post again if your recommendations aren't sufficient (I'm tempted to employ both versus one over another!)

Take care,
Susan