Topic Options
#31472 - 07/31/09 09:38 AM Dynamic Data Page size to Round Robin queues, keeping jobs together
Justin K Offline
OL Toddler

Registered: 05/13/09
Posts: 40
Loc: Atlanta, GA, USA
Hello again,

I have a process that queries rows from a database, splits them into data pages with number of records per data page based on the document they will be inserted to, and then sends them to a certain round robin queue of printers (also determined by document). I wish for the output for one "job" to remain together on one printer rather than each data page sent to the next printer in the round robin.

Here is an outline of my current design:

I have DocA, DocB, DocC going to RoundRobin1, RoundRobin2, RoundRobin3. DocA has 1 record per document (therefore 1 per Data Page), DocB 2, DocC 3.

PP Database (many records on one Data Page, sorted by Doc Name)
|
DB Splitter (split to new Data Page when Doc Name changes)
|
Conditional DB Splitter if DocA (split to 1 per data page)
|
Conditional DB Splitter if DocB (split to 2 per data page)
|
Conditional DB Splitter if DocC (split to 3 per data page)
|
Conditional Print to RoundRobin1 if DocA
|
Conditional Print to RoundRobin2 if DocB
|
Conditional Print to RoundRobin3 if DocC

At the point of printing to the Round Robin queues, each document page cycles through the printers in the round robin -- this is not desired. I wish for all data pages of the current document to finish on the first printer, then the next batch to continue on the next printer etc. In other words, if all data pages of DocA could be merged into one "job" before hitting RoundRobin1, ensuring all pages of this "job" finish on the same printer in RoundRobin1.

How can I accomplish this? Is there a way to merge the data pages as I mentioned? Perhaps a better way of splitting my data to ensure my output is as I desire?

Any suggestions are much appreciate.

Thank you,

-Justin

Top
#31473 - 08/04/09 11:56 AM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Anonymous
Unregistered


Hi Justin,

If I understand this right, you seem to use the round robbin to share the load to printers and maximize printing speed. If this is the case, I suggest you use SNMP conditions instead.

Replace a single printer queue that has 3 printers selected, by 3 different printer queues that use only 1 printer each. Before each printer queue, you will put an SNMP condition that will evaluate if printer is available, and go to the next if it's not. That way, the documents you print will stay grouped together by Doc Type, but will always print ASAP.
Code:
 
  |
  | 
 ...
data for Doc A or B or C
  |
  |
  |
|----| SNMP cond.
|    |-----|
|----|     |
  |      -----
  |      |   | printer queue 1
  |      |   |
  |      -----
|----| SNMP cond.
|    |-----|
|----|     |
  |      -----
  |      |   | printer queue 2
  |      |   |
  |      -----
|----| printer queue 3
|    |
|----|     
If it is not what you meant, please explain your exact needs further. Thanks.

Regards,

Olivier

Top
#31474 - 08/05/09 10:10 AM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Justin K Offline
OL Toddler

Registered: 05/13/09
Posts: 40
Loc: Atlanta, GA, USA
Hi Olivier,

I understand your suggest, but I would experience a similar issue to what I am facing now by using SNMP conditions in this way. Let me explain..

In my example, DocC has been designed to expect 3 Records in each Data Page:

Printed Page 1 = Data Page 1 (3 records)
Printed Page 2 = Data Page 2 (3 records)
etc.

To get my data in line with this:

Database Splitter
when Doc Name = "DocC"
where to split 0
Split when condition is found 4 times

First 3 records are the 1st Data Page, 4th record will start next Data Page, and so on.

By using this splitter, my job has now been split into multiple jobs. Job1 (from Data Page 1) will then hit the Round Robin or SNMP conditions first, next Job2 (from Data Page 2) will. In the case of using SNMP conditions, the first printer is now in use by Job1, so Job2 goes to the next etc.

As you can envision, this splits the Data Pages apart among multiple printers.

What I need is for all the DocC Data Pages to end up at one printer.

It seems I need to either:

- Not use a splitter to place the correct number of records on each Data Page for a document. Then, how do I handle this? As I mentioned in my first post, each document has a different quantity of records displayed per printed page. Using Data Pages of the appropriate size seems the right way to do this.

or

- Somehow merge or group the Jobs after they are split so that Job1, Job2, Job3 for DocC all end up at one printer in the bank of available printers.

I thought this was going to be simple smile

Thank you very much your help.

-Justin

Top
#31475 - 08/05/09 05:34 PM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Anonymous
Unregistered


Hi Justin,

The variable amount of records per data page should be handled in the form design. In watch, you should only have to split at Doc type change. If you really need to split your data pages in Watch, then you can put a document type splitter before the SNMP conditon, then split again per data page after the SNMP condition right before your printer queue output. That way all your "datapages" for one document type will go to the same printer.

Please let me know if I did not understand your need. You can also open a support call if you feel we could help you better by looking at it. Thanks.

Regards,

Olivier

Top
#31476 - 08/06/09 02:19 PM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Justin K Offline
OL Toddler

Registered: 05/13/09
Posts: 40
Loc: Atlanta, GA, USA
Hi Olivier,

I honestly had not considered handling the variable records per data page in the document design. I think this could be the best answer!

Currently:

For documents in which I can use Repeat (have regular spacing), I'm using a "Line repeat" and accessing fields with something like Field('Name',¤t.line).

For those which I cannot use Repeat, I am simply using Field('Name',1) then Field('Name',2) etc for however many records per document page (which is the size of the Data Page).


If I am able to do as you suggested, and can handle the variable records per data page in the document, it also will greatly simplify my overall process in Watch.

If we take an example of a document which has 3 records worth of data displayed on 1 document page.

Then assume we send 10 records to it (as in, we are not guaranteed our data will come in groups divisible by 3 -- the last output page produced will contain only 1 record, in this case).

Could you please give a quick example of handling this data in the design of my document without needing to split it into appropriately-sized Data Pages in Watch?

Thanks for your response, Olivier!

-Justin

Top
#31477 - 08/06/09 02:30 PM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Anonymous
Unregistered


Hi Justin,

The best way to deal with variable amount of data per record in a form is to create a simple overflow logic, using the native feature from a data selection object in the line repeat tab (condition to exit and overflow...) With this option properly set up, you can tell your form to show a maximum of 3 "iterations" per sheet of paper, and have a new page automatically created as needed to continue showing the data until it reaches the end of the repetitions, no matter how many there are in total and no matter how many will remain to show on the last page. There are tutorials on how to use this method here
The last 2 tutorials are the ones for you. Note that they use XML data, but the DB approach is very similar. Please have a look at them and let us know if you have further questions.

Thanks. Regards,

Olivier

Top
#31478 - 08/10/09 04:39 PM Re: Dynamic Data Page size to Round Robin queues, keeping jobs together
Justin K Offline
OL Toddler

Registered: 05/13/09
Posts: 40
Loc: Atlanta, GA, USA
Olivier,

I've had great success with this method. Thanks for the suggestion!

-Justin

Top