Configuration manager

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: http://www.promes.com/prodbx_xml.asp.
• 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 Outlook Express).
    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 the dispatcher
• 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 mail.
• 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.