Communicating with the dispatcher
Clients can communicate with the dispatcher
using one out of three possible communication protocols.
- DCOM: The usual way when clients are on the
same network as the dispatcher, or the client is running on the same machine
as the dispatcher.
- XML (MAIL): Transactions are packed in an
XML file and send to the dispatcher as an attachment of a mail message.
- XML (HTTP): Transactions are packed in an
XML file and send using the standard HTTP protocol. Dispatcher is mandatory to
run on a server machine having an Internet Information Server running as well.
You can configure the way the client
communicates with the dispatcher by selecting the second tab in the properties
screen of the connection.
- Dispatcher protocol: Select the
protocol as explained here above. Some of the fields on the screen will be
disabled or enabled depending on the selection you make.
- Ping Option: when a client is
communicating with the dispatcher
or vice versa it is using DCOM. When the dispatcher is not available,
because the dispatcher's machine is not running or the network is down your
client may experience performance problems. The timeout of not being able to
communicate through DCOM is very long, and in some exceptional cases your
client may even hang. To avoid this you can set the ping option to True.
With this the client will 'ping' the dispatcher's machine before executing
the DCOM function. If the 'ping' fails then the DCOM instruction is not
executed, and queued for the next attempt. After 5 consecutive 'ping'
failures the connection with the dispatcher will be set unreachable. This is
the mode where the client will not try to reach the dispatcher's machine any
more on each function call, but only retry to establish connection every 1
minute. Please remind:
- PING uses only TCP/IP.
- It does not make sense to enable the
ping option when the client is running on the same machine as the
dispatcher runs on.
- The same mechanism applies from the
dispatcher's machine and the transaction handler's machine where the
client is running on.
- If you want to have your connection
between client and dispatcher reliable, or you expect communication
breaks to happen frequently (often with dial-up networking) the you
should enable this option (and therefore have TCP/IP installed).
- Url: Full address of the webpage to
send and receive the xml files from. Example:
Mail software: you can select:
Internal: this is the PRODBX internal mailing
program. It doesn't need any other mailing software or special drivers to be
installed on your machine. Further settings, such as POP3 and SMTP addresses,
are configured in the connection client itself.
Incoming and outgoing mail is stored in 2 subdirectories of your client or
dispatcher (Inbox and Outbox). Mail messages are stored with .eml format, and
therefore readable by a number of common mailing programs (such as Microsoft
PRODBX will never delete or clean-up old messages.
Outlook: selecting this will make the client use
the Microsoft Outlook MAPI spooler, and send mail on behalf of the user logged
on the system. Messages sent by the dispatcher are stored in the inbox of that
same user. PRODBX will scan the inbox for the existence of a message with
subject '##PRODBX##', read it, interpret it, and if successful transacted,
delete the message.
However: as of Outlook 2000 Service Release 1, there might be a number of
security issues because Microsoft Outlook does not allow external programs to
use the MAPI spooler. You will get a number of popup messages asking you if
PRODBX is allowed to use your mailing program. In a standalone version of
Outlook, there will be nothing to do about this situation. If you use Outlook
together with the Microsoft Exchange Server, then there are a couple of
solutions Microsoft provides on its website.
Mail of dispatcher: the e-mail address of
- Mail of this
client: the e-mail address of the client you are configuring
Check mail every (min): mail is not send
each time there is a new transaction. Mail is send every number of minutes
specified in this parameter, for all the transactions generated since the last
- ZIP XML files: if
XML files are too big to be useful, you can ask PRODBX to zip them before
attaching them to a mail, or before sending them to the webpage.
Max txns/message: if you have too many
transactions during a specific period of the day, you might end up with
extremely large XML files. This might give you problems with the size of the
mailbox you are sending the message to. Therefore, you can limit the number of
transactions being handled per mail message, by defining a value for this
parameter. Per default, PRODBX will always limit the number of transactions to
5000. This maximum value is written in the registry and can be modified.