OVERVIEW about the features of the BID server

EMails are quite common in the business reality. Humans are using eMails to communicate with business partners or to distribute information. The eMail software is an important part of every IT installation and everybody using this on a daily basis.

In addition your IT installation is target of permanent changes from shifting your staff to an other project up to setup and maintain a new processes. Every changing require a update of your business-processes to link the sender of business-information with the right receiver.

To keep your IT in sync with your business the BID server was designed to reduce your the work-load and to organize your network relations. As a goal every sender of business-information use the BID server as the receiver and the BID server is using a business-rule as a plugin to decide how to handle this business-information. For every business-information a different plugin is used. The link between an incoming business-information and a plugin is done using the subject line of the incoming business-information-eMail:

  path/to/myplugin@additional data

With everything up to the first @ (in this case: path/to/myplugin, the @ is required) is the path to the plugin relative to the plugins directory of your BID server installation

A plugin can be as easy as rewriting a header up to do complex calculations.
To rewrite a header a one line command is used (from: path/to/myplugin.tcl) :

SetHeader From "MyFromEMailAddress" To "MyToEmailAddress" Subject $SUB

With SUB is your subject after the first @ character.

• This is an example of your first business case automation.

Every sender of an eMail using this plugin will use the MyToEmailAdress as target for receiving eMails. If the receiver is changing or some other header information have to be changed you only have to update this plugin and not every sending application. This easy example is showing you the power of the BID server and the easiness of dis-linking sender and receiver.

If you step into this tool you probably want to do more than just rewriting headers. Some processing of the information available in the body of the eMail would help you to classify your eMail better. The mime getbody command gives you everything need to work with the body:

set MY_BODY [mime::getbody $TOK]

With TOK is the handle to your current eMail object.

If your are lazy and if you don't want to parse the body by your own the BID server can do it for you with a little help in formatting of the incoming eMail (this is an example of a shell script try to send a business relevant information to your BID server using a pre-formatted body) :

mailx -s "path/to/myplugin@my alarm eMail" bid@server <<EOF
><TokenNr1:this is a single line data
>TokenNr2
1. multi-line data
2. multi-line data
<TokenNr2
EOF

with bid@server is the eMail account of the receiving BID server.
The plugin need the following line to read this data:

array set MyVariable [ParseBody]

with MyVariable(TokenNr1) defined a normal variable and MyVariable(TokenNr2) defined as list.

If data is required you can add the token to the command-line of the ParseBody command and the BID server will generate an error if the token is not available:

array set MyVariable [ParseBody TokenNr1 TokenNr2]

If you are able to parse the incoming eMail body you are able to convert your eMail into a more readable format and to provide a common style for your corporate identity. The BID server provide you with the ability to convert your eMails into HTML eMails. A plugin for this case would look like this:

package require email

array set VAR           [ParseBody TokenNr1 TokenNr2]

email::Classify         $HOST

set email::HEADER       "HTML test email"
set email::SUBJECT      "used to test the local setup"
set email::ROWS         [array get VAR]

::email::MakeBodyToHTML info.htm

SetHeader   To [GetFrom] Subject $SUB

creates the eMail test HTML email body with the parts:

• package require email
  • load the html eMail package
• email::Classify
  • setup the colors and the priority of the eMail. The classify is done using the lib/libClassify.tcl library
• email::HEADER and email::SUBJECT
  • set special header fields in the HTML eMail
• email::ROWS
  • requires a LIST as input based on key and value parts to setup the data in a table like structure
• email::MakeBodyToHTML
  • finally create the eMails using: template/info.htm

After you are able to create your own customized eMail the need to setup a more complex business-rule exist.
To create a persistent workflow a data storage is needed to split a business-case into steps and exchange data between the steps.
Data can be stored with:

db::Write token value

using token as key and value as data.
To read the data use:

db::Read token ?default?

using token as key and the default if the key is not available
Together with the ability to use multiple plugins and the ability to store data you are able to create a persistent workflow.

---