It is always important to understand the basic concepts of any product that you will be using. Understanding the different components that make up the JBuddy Message Server will help you make the most of the platform.
We will start by discussing the versions prior to the latest release, version 3.0 which began shipping in June 2006. As you will discover, the new version offers significant improvements in management and user features over the prior, 2.0 version.
Prior Architecture (Version 2.0)
In releases prior to version 3.0, JBuddy Message Server shipped with only one IM gateway; the JBuddy Protocol Gateway, which provided secure, archived private enterprise IM. Connectivity to public IM and enterprise IM networks was available through the multi-network enterprise IM client, JBuddy Messenger Pro as shown in Figure 1-1 below.
Figure 1-1: JBuddy Message Server Architecture version 2.0
Current Architecture (Version 3.0)
JBuddy Message Server 3.0 represents a big leap forward in the JBuddy Message Server product evolution. It offers substantial benefits to organizations in many areas, including IM management and control, operations, user features, mobile uses, and development and system integration.
In Figure 1-2 below, you can see the current JBuddy Message Server 3.0 architecture. As in prior releases, it shows how all of the server components remain behind the corporate firewall while communicating with the outside world through the firewall. What’s new in version 3.0 is the ability to centrally manage and log all external communications, as well as route both public IM and enterprise IM to specific users including mobile E-Mail users. Version 3.0 supports an optional message gateway called Instant Help described in a subsequent chapter. By centrally managing external connectivity, the enterprise achieves greater control and reduces potential security threats and misuse while at the same time, bringing all users including mobile users under message archival for regulatory compliance. Connectivity to public IM can still be achieved directly through the JBuddy Messenger Pro IM client if external file transfers are allowed at your organization.

Figure 1-2: JBuddy Message Server Architecture version 3.0
Public IM is represented on the left side of Figure 1-2 by the MSN and AIM icons connected to their respective Public IM network clouds. A Blackberry icon represents an enterprise mobile user with an E-Mail enabled wireless device. This mobile user may or may not play a role in a JBuddy Message Server deployment depending on server configuration. On the right side of Figure 1-2 (inside the corporate firewall), several components which make up the JBuddy Message Server architecture are shown. The JBuddy Message Server consists of several components or services including an authorization / load balancing server, and multiple message gateways.
The Database server was omitted from Figure 1-2 but plays a critical role in the overall server architecture by persisting IM account data, routing rules, buddy lists, privacy settings, message archival for regulatory compliance purposes, and buddy presence. The presence stored in the database can form the foundation for other useful applications such as the display of presence information to a live web page or with email as a presence enabled URL as depicted in Figure 1-3 below. These applications are made possibly by leveraging the live presence updated in the database and using the new Presence Servlet new to this release.
Figure 1-3: Leveraging Presence in Applications
External connectivity management and control is one of the major enhancements to the server in this release. To facilitate central management and mobile messaging, a message routing engine along with server-side public IM gateways, enterprise IM gateways, and other gateways including an SMTP message gateway are introduced to the server options. To facilitate web based live support, version 3.0 also introduces a sophisticated Instant Help message gateway.
In order to run the JBuddy Message Server installation program as well as the server itself, you must have a Java Virtual Machine (JVM) version 1.4.x or newer installed. By JVM, we are refering to either Java Runtime Environment (JRE) or Java 2 Standard Edition (J2SE) 1.4.x or newer. If you plan to enforce SSL login and message encryption, you must have JVM version 5.x or newer installed prior to running the server. The JBuddy Message Server installation program as well as JBuddy Message Server itself are written entirely in Java and should therefore run on any JVM 1.4.x or JVM 5.x enabled modern operating system. That said, the server startup and shutdown scripts and any operating system “services” used to run the JBuddy Message Server utilize a free, open source, native library called Java Wrapper Service (JWS) to facilitate better native operating system integration such as with Windows Services. If you plan to operate the JBuddy Message Server software on an unsupported operating system, you may be able to compile a JWS library appropriate for your platfrom by obtaining the source from http://wrapper.tanukisoftware.org/ . If necessary, the JBuddy Message Server can be operated without the startup / shutdown scripts by passing the proper arguments directly to the JVM from a script, command shell or terminal. Instructions for custom JWS library compilation and non-JWS startup/shutdown are beyond the scope of this guide.
You may use JRE 1.4.x or 5.x obtainable by from http://www.java.com/ by following the download instructions for basic demo or small deployment scenarios, however for best performance and scalability, we recommend using the full featured J2SE 5.x obtainable from http://java.sun.com/j2se/ by follow the download instructions. The J2SE edition supports the -server flag which is the intended use of JBuddy Message Server. You may also experimentally try another JVM implementation from vendors such as IBM, Apache, and Blackdown.
During installation, if the Installer encounters more than one JVM, it will make a 'best guess' on which Java environment to use. It updates .conf files located in the conf directory. Near the top of these files it sets the property 'wrapper.java.command=$JAVA_HOME/bin/java' and then a little lower it updates the classpath wrapper.java.classpath.1=$JAVA_HOME/lib/tools.jar'. The $JAVA_HOME variable is replaced with the 'JAVA_HOME' that the Installer believes is the correct version. If you wish to use a different JVM, you will need to edit the values above. Also if you desire to use the -server flag for performance reasons, you will need to use a Java version that includes support for this feature. On Windows and OS X, the typical JRE 1.4.x does not, but on Linux it does. You can determine if your JVM environment supports this by typing the following in a command shell or terminal: java -server -version which should tell you the version of java used as well as if it is the server or client version of the virtual machine.
Command Line Installation
Initially you will need to run the installation on a computer with a graphical interface (see Launching the Graphical Installer below). At the end of the installation, you will be prompted if you wish to save the installation as an XML installation script which can be used later for an automated (non-graphical) installation such as on a remote Linux or Unix server. If this is your situation, you need to enter information applicable to the remote host when prompted during the Installer. To run the headless installation, copy the installer jar file and xml install script saved at the end of the GUI install to the remote host. Then login to the remote host and from a command shell or terminal, enter as follows:
java -jar JBuddyMessageServerInstaller-3.x.xxxx.jar JBuddyServerInstallScript.xml where the JBuddyServerInstallScript.xml is whatever name you saved at the end of the GUI install.
After JVM 1.4.x or 5.x is properly installed, double click on the JBuddyMessageServerInstaller-3.x.xxxx.jar file to launch the installation program. If you prefer, you can launch the Installer by simply entering the following from a command shell or terminal: java -jar JBuddyMessageServerInstaller-3.x.xxxx.jar. Once launched you should see a small Language Selection dialog appear similar to Figure 2-1 below:
Figure 2-1: Installer Language Selection Dialog
After selecting eng (English) language and clicking OK, the Installation Welcome window appears similar to Figure 2-2:
Figure 2-2: Installation Welcome
After clicking Next, the Installation Information window appears similar to Figure 2-3:
Figure 2-3: Installation Information
After clicking Next, the License Agreement window appears similar to Figure 2-4. You must accept the terms of the license agreement before the Next button will permit proceeding to the next screen.
Figure 2-4: Installation License Agreement
After accepting the license agreement terms and clicking Next, the installation path must be specified as in Figure 2-5 below. Once Next is chosen an Message dialog appears to inform you that the directory will be created (or if it already exists).
Figure 2-5: Installation Location
After clicking OK to the Message dialog, the Installation Registration window will appear where you should enter your organization name and paste in the license key you received from Zion as in Figure 2-6 below. If the license key is not entered properly, or has expired a Input Problem dialog will appear. The best way to avoid this error with a valid license key is to copy and paste since 1s and ls and Os and 0s are often difficult to distinguish.
Figure 2-6: Installation Registration
After pasting a valid license key into the License String input field and clicking Next, the Installation Package Selection window will appear similar to Figure 2-7 below:
Figure 2-7: Installation Package Selection
The Package Selection window shows mandatory and optional “packs” that can be installed. Clicking a individual pack changes the description shown. For example, if you don’t have plans to leverage Lotus Sametime or ICQ, you can uncheck the pack(s) and it will not get installed. Just because you install a particular pack doesn’t mean you have the proper license to enable that feature. An improvement of the Installer would only enable the products packs which you hold a valid license to use. Once you are satisfied with your packs selection, click Next to proceed.
After clicking Next, the Installation Configuration window will appear similar to Figure 2-8 below. Server Hostname is the IP address or fully qualified domain name of the machine where JBuddy Message Server will operate once installed. If it will ultimately live on a remote headless machine, enter that host name or IP here.
Figure 2-8: Installation Configuration (part 1)
The Sys Admin UserId is a login userid for administering the JBuddy Message Server. It is not related to operating system authorization credentials. Confirm the chosen password by reentering it in the Confirm Password input field. The Database Secret field is also a password field of sorts. It is used to encrypt all user account passwords with 192 bit Triple DES encryption into the database. It should be noted that although the account passwords are very securely encrypted, the Database Secret must be accessible by the server at runtime to unencrypt the passwords on demand and therefore, utmost care should be taken to protect the JBuddy Message Server configuration files from unauthorized access or view.
After clicking Next, the second Installation Configuration window will appear similar to Figure 2-9 below. E-Mail From is the email address used for emails sent from the JBuddy Message Server such as for lost passwords. The Smtp Host is the fully qualified hostname of the SMTP mail server that JBuddy Message Server will use to deliver the email. If the SMTP mail server requires authorization to login before sending email, the Smtp User and Smtp Password should be entered. If not, leave them blank.
Figure 2-9: Installation Configuration (part 2) Figure 2-10A: SMTP Configuration
After clicking Next, any optional Installation Configuration windows will appear similar to Figure 2-10A-D if you selected the SMTP Gateway, Lotus Sametime, Microsoft LCS or Jabber packs respectively during the Installation Package Selection window (Figure 2-7).
In Figure 2-10A, the current Installer prompts for an IMAP Host, IMAP User and Password, however the configuration file for the SmtpMsgGateway.properties file may be configured for POP email retrieval by changing the correct properties in the future.
If you selected any other enterprise IM packs to be installed such as Lotus Sametime or Microsoft LCS or Jabber, you will be prompted to provide the hostname of the EIM server similiar to Figure 2-10B, 2-10C, 2-10D) below.
Figure 2-10B: Lotus Sametime Configuration
Figure 2-10C: Microsoft LCS Configuration
Figure 2-10D: Jabber Configuration
After clicking Next, the Installation Process (Figure 2-11) will begin and you will see progress bars as the packs are written to the directory specified in the Installation Location window (see Figure 2-5). Once this process is complete, the Next button will become active.
Figure 2-11: Installation Progress
After clicking Next, the Installation Post Install Processing window will appear similar to Figure 2-12 (Mac OS X) below. If the Installation is believed to be successful, the Next button will be enabled once more.
Figure 2-12: Installation Post Install Processing (Mac OS X)
On Windows, the Installer will attempt to register the JBuddy Message Server and JBuddy Message Server Admin Console as services with the operating system and start them. The log output from Post Install Processing will appear in the window as well (Figure 2-13). If the Installation is believed to be successful, the Next button will be enabled once more.
Figure 2-13: Installation Post Install Processing (Windows)
After clicking Next, the final Installation window will appear as shown in Figure 2-14 below. You can save this GUI installation as an XML script for a repeatable non-gui installation, by clicking the “Generate an automatic installation script” button before finishing.
Figure 2-14: Installation Success / Save Installation Script
JBuddy Message Server consists of two servers and one or more message gateways. The servers are JBuddy Message Server and JBuddy Message Server Admin Console. The JBuddy Message Server Admin Console runs as a web application with an instance of Jakarta Tomcat 5 which is a web server with Java Servlet and JSP support. The JBuddy Message Server Admin Console is only required for configuring accounts, routes, viewing message archives, etc and is not critical to the message routing of the server.
On Windows 2000, Windows 2000 Server, Windows 2003 Server and XP Pro, both services are installed and started automatically in the background as "windows services". Log output shown in the Installation Post Install Processing window (Figure 2-13) would typically indicate the success or failure of the services launch during installation. At any point after the installation, you can view the current running status of the JBuddy Message Server services on a Windows Machine by viewing the Windows Services Panel, (Extended) (Figure 3-1). If the Status is “Started” this indicates the service is running. To shutdown the server on Windows, select the JBuddy Message Server service and click stop the stop button. The JBuddy Message Server Admin Console will also be stopped as it depends on the JBuddy Message Server service. This may take a minute. To start the Server, select each of the JBuddy services and click the start button. After a few seconds the Services panel should refresh and update the services Status to “Started”. If one or both of the services fail to start the Windows Event Logger will show the failure.

Figure 3-1: Windows Services Panel
Linux, Solaris, Mac OS X, BSD, etc
On Linux, Solaris, Mac OS X, or another flavor of 'unix', the Installation process does not launch the server. You will need to invoke two shell scripts from a command shell or terminal. If having the server available after reboot is desired, add the scripts to the etc server startup scripts. For now, just open command shell or terminal and change to the installation directory. Next enter ./bin/server.sh start to start the server and ./bin/admin.sh start to start the admin console. Gateways can be started with ./bin/xxxGateway.sh start were xxx is the pre-fix of the desired message gateway. Use no arguments to see the other options (stop, status).
Inside the installation directory is a conf subdirectory which contains JWS and JBuddy Message Server configuration data for servers and gateways. Various configuration parameters may be modified by carefully editing the .conf files and restarting the servers and gateways. A backup copy should always be made prior to editing in case a simple typo is introduced preventing the server or gateway from starting. Important parameters include: -server JVM argument to specify the server JVM (no -D is prepended), System properties to enable SSL encryption, message archival, and logging levels, whether to use an external database or not, and many more. Consult the comments within each of the .conf files for details. Below is a table of useful Java System properties that may be set in the .conf files by adding new wrapper.java.additional.X=-D where X is the next highest level and the property name=value is appended after the -D (no space) unless otherwise noted.
|
|
|
|
|
|
|
|
|
uses the server JVM instead of the client JVM for server side applications. No -D is prepended.
|
|
|
|
|
enables the AggressiveHeap garbage collector in the JVM for high load servers. No -D is prepended.
|
|
|
|
|
Disable embedded HsqlDB engine
|
jbuddy.disable_message_archive
|
|
|
Disable message archiving
|
jbuddy.use_rich_text_in_message_archive
|
|
|
Archive message in native rich text format instead of plain text
|
jbuddy.auto_reply_seconds
|
|
|
Number of seconds of idle to resend auto_reply message
|
|
|
|
|
This is READ ONLY after installer. Triple DES key used to encrypt passwords.
|
|
|
|
|
Enable SSL login and message encryption (applies to JBuddy Gateway and JBuddy Message Server)
|
|
|
|
|
default log level for JBuddy Message Server and all components
|
|
|
|
|
Spawn a logger thread to try to order the incoming log requests according to FIFO order
|
Table 3-1: Server Properties
Additional Server properties are located in various properties files located inside the lib subdirectory.
Inside the installation subdirectory is a logs directory where both servers store logs. The JBuddy Message Server logs to server.log while the JBuddy Message Server Admin Console writes to the admin.log. The gateways log to xxxx.log where xxxx is the corresponding gateway name. In addition Jakarta-Tomcat may also log other messages to jakarta-tomcat/logs. The logging level of various processes managed by the servers may be changed carefully and the servers restarted. The JWS .conf parameters also specify how large a .log file will grow before it is replace and how many log files will be rotated. The table below outlines various JBuddy specific log levels that can be enabled depending on the desired output. jbuddy.logLevel is bit-wise ANDed with the log level of the log call to determine if it will be logged, therefore you will add the values you want to arrive at a log level. Ie: if you want to log EXCEPTIONS, ERRORS, WARNINGS across all JBuddy processes, you would add the values from the table below to arrive at the logLevel: jbuddy.logLevel=7
Table 3-2: Log Levels
For more fine-grained control over logging, individual components can have their logLevel set by adding a System property to the MessageServer.properties file after the specified component. For example. To turn on EXCEPTION, ERROR, WARNING, and PRESENCE and MESSAGE logging for the AIM Gateway, we would enter the following using the values from the Log Level Table above:
com.zion.messaging.aim.AimMsgGatewayImpl.logLevel=775
Inside the installation directory is a hsqldb subdirectory where the HSQLDB database server is installed. This is a simple yet powerful open source relational database written in java. Using a .conf option, the JBuddy Message Server can be told to use an external database such as Oracle, Sql Server, My SQL, etc rather than HsqlDB if desired. Presently the JBuddy Message Server controls the start and stop of HsqlDB. JBuddy Message Server communications with the database through a properly configured JDBC driver.
To provide a database column sequencer that works with any database, JBuddy Message Server includes a process called the ObjectIdServer. This process acts as a object id (primary key sequencer) generator for many of the database tables used by JBuddy Message Server. Therefore, careful care should be made not to manually insert rows into any databse table with an ID field while the server is running, otherwise the ObjectIdServer may become out of sync for that database table.
Creating Accounts with SQL
Although we haven’t covered User level accounts up to this point, this section will detail how to correctly create User level accounts in the database such as for a bulk loading of users by directly updating the database with SQL.
1. Shutdown the JBuddy Message Server service.
2. In a command shell or terminal, start only the database (run hsqldb.sh)
3. Run the DatabaseManager command line interface tool:
cd into the hsqldb directory
java -cp lib/hsqldb.jar org.hsqldb.util.DatabaseManager
4. Login to the HsqlDB and change login fields to:
Type: HSQL Database Engine Server
Driver: org.hsqldb.jdbcDriver
URL: jdbc:hsqldb:hsql://localhost
User: sa Password: <blank>
example SQL:
INSERT INTO ACCOUNT (ID, NAME, NICK_NAME, MSP_ID, U_ID, BUDDY_LIST_VERSION, BUDDY_LIST_PERMIT_MODE, NUM_MESSAGES_SENT, NUM_MESSAGES_RECEIVED, PASSWORD, KEEP_ALIVE, AUTO_REPLY_MSG, SERVER_HOST, SERVER_PORT)
VALUES (1, 'bart star', 'bart', 99, 'admin',0,1,0,0, 'password', 'T', 'This conversation is being logged by JBuddy Message Server', null, null)
For enterprise IM using the proprietary JBuddy protocol, the JBuddy Message Server load balancer process listens on port 1424 and the JBuddy Gateway listens on 1425 by default. These can be modified prior to startup by carefully editing the MessageServer.properties file within the lib subdirectory. The load balancer listening on port 1424 redirects connecting clients to connect to the JBuddy Gateway running on port 1425 on the same host or other hosts if JBuddy Message Server is configured for enterprise clustering. The JBuddy Message Server Admin Console runs as a web application within Jakarta-Tomcat and is available by default by pointing your browser to port 8080, although configuring Jakarta-Tomcat to run in parallel with the popular Apache web server on port 80 is very common but beyond the scope of this guide. Other network ports used by JBuddy Message Server may include additional ports opened by Jakarta-Tomcat, HsqlDB (see Jakarta-Tomcat and HsqlDB documentation for details), and Java’s RMI (port 1099 by default). Various other optional message gateways use additional ports and are documented in the section specific to the gateway.
External Access while behind a NAT Router
Normally enterprise IM is configured for privacy and security with no external access permitted. However, if the JBuddy Message Server is used for an internet portal or online community, then external access is required. If the host that JBuddy Message Server is installed on is reachable from the internet with a fully qualified domain name or internet IP, there is no problem. However, if the host that JBuddy Message Server is installed on is only visible from the private network, an additional setting is required. The JBuddy Message Server may be configured to listen for connecting clients from the internet while running on a private IP network such as 192.168.x.x behind a NAT Router by adding the following System Property to MessageServer.properties located in the lib subdirectory:
JSC_HOST_DMZ=externalhostname or IP
The private hostname or private IP is still required during the installation process since this is the hostname or IP address that the JBuddy Message Server load balancer and the JBuddy Gateway bind to, however with the JSC_HOST_DMZ property set, the JBuddy Message Server load balancer will return the external host name or internet IP address to clients that connect rather than the default hostname or IP that the JBuddy Gateway binds to which would be unreachable from the internet. It should be noted that if this setting is utilized, internal clients may be unable to connect if they are unable to connect to the external address from inside. This may be remedied with a proper route entry added to the NAT router, although this is beyond the scope of this guide.
Each user who will have the ability to configure Accounts within JBuddy should have their own User Profile. A User Profile consists of a user id and password and other contact information. The Sys Admin User Id is created during server installation. If central control of all accounts will be handled by the Sys Admin for the JBuddy Message Server, then no additional User Profiles need to be created. The default Central Account Management screen is shown in Figure 4-1A below.
Figure 4-1A: Central Account Management Screen
If each user will be able to manage their own Accounts such as for a hosted service, then each user should to have their own User Profile. Please request the hosted-version of the JBuddy Message Server from Zion Software if this is your intended use. It differs slightly from the non-hosted version (see Figure 4-1B) and provides users with the ability to create their own User Profile. To create their own User Profile, users will click on the Sign Up Now link from the homepage and completing the User Registration form (Figure 4-2).
Figure 4-1B: Hosted Account Management Screen
Figure 4-2: User Registration Form
With a valid user ID and password (either the Sys Admin or one created using the User Registration form in Figure 4-2), a user can login to the JBuddy Message Server Admin console by entering their user ID and password in the User Name and Password fields shown in Figure 4-1, or may login via a WAP enabled mobile device but pointing the mobile device browser to:
where hostname is the hostname or IP of the server hosting the JBuddy Message Server Admin Console and 8080 is the port where the Admin Console is available (could be port 80 or 443 if accessed through a web server such as apache).
Upon login the user will be presented with the Welcome page (Figure 4-3).
Figure 4-3: Welcome to the Admin Console
From here, the user can access various pages in the Admin Console by either clicking on the links in the Welcome page or clicking on the tabs across the top. Since this is a newly created User, we will begin with the Account Manager.
All connectivity in the JBuddy Message Server centers around Accounts. There are IM Accounts and there are other non-IM Message Accounts. A user may have more than one Account since JBuddy Message Server version 3.0 is capable of connecting to five (5) public IM networks and four (4) Enterprise IM servers in addition to the other messaging services. After clicking on the Account Manager link or top menu tab, the Account Manager Admin screen appears (Figure 4-4):
Figure 4-4: Account Manager Admin
Since this is a brand new user profile, there are no accounts visible in the table. After clicking on the Add Account, the New Messaging Service Account screen appears (Figure 4-5):
Figure 4-5: New Messaging Service Account
The Message Service Provide drop down list offers a list of public IM, enterprise IM and several other messaging service types. Depending on the license(s) installed, this list may be different. After selecting the desired Messaging Service Provider, the default fields may change.
JBuddy Enterprise IM Accounts
In Figure 4-6 below, the JBuddy Message Server drop down choice is selected as shown by the JBuddy icon (red, green and blue people). If you are only interested in private, enterprise IM using the JBuddy Message Server, you only need to create JBuddy Message Server IM accounts. Once JBuddy accounts are created, all that’s required to start using the JBuddy Message Server for private enterprise IM is to configure the JBuddy Messenger / Pro IM clients to point to this JBuddy Message Server instance (configure the host in the IM client) and login with the above screen name and password. This is discussed in a subsequent chapter on the IM client.
Figure 4-6: New JBuddy Message Server Account form
In Figure 4-7, we’ve selected AOL Instant Messenger Messaging Service Provider as indicated by the yellow triangle representing AIM.
Figure 4-7: New AIM Service Account
The Screen Name and Password fields are required for all IM messaging accounts and represents a valid screen name of the selected Message Service Provider. The Password and Confirm Password input fields are where the valid password for this screen name are entered. Optional fields for the public IM and non-JBuddy enterprise IM accounts include the Auto Reconnect on Disconnect checkbox, Privacy, Nick Name, and Auto Reply fields. The non-JBuddy enterprise IM services including Lotus Sametime, Jabber / XMPP, and Microsoft LCS also require Server Host and Server Port fields to be provided in order for JBuddy Message Server to know where to connect.
The Auto Reconnect checkbox informs the JBuddy Message Server to attempt to maintain an active connection for this screen name. An invalid screen name or password would prevent this. The Privacy drop down list specifies how the IM account handles messages from other buddies. Permit All allows all messages, Permit Some allows messages from the buddies on the Permit / Allow List. The Deny Some privacy setting blocks messages from the buddies in the Deny List but allows messages from all others. Lastly, the Deny All privacy setting prevents messages from everyone which is not often used. The Nick Name field is often used by IM services as the Display Name seen by other buddies. The Auto Reply or Disclaimer field can be used by the server to send an automatic reply to a new conversation with a buddy, potentially to let them know the conversation will be logged, or to let them know the messages are being forwarded to a mobile device.
After creating several message accounts, the Account Manager Admin screen would look similar to Figure 4-8 below:
Figure 4-8: Account Manager Admin
Notice in Figure 4-8 how the status is blank for all the services. This is because the accounts are not yet active.
In order to active the message accounts creating in the IM Accounts screen, they must be associated with another message service. In the JBuddy Message Server Admin Console, this message account association or mapping or routing is termed, ‘IM Account Forwarding’ and it is available as a sub menu on the left side of the screen in the Account Manager below ‘IM Accounts’ (Figure 4-9 below).
Figure 4-9: Instant Messaging Account Forwarding Admin (no routes).
After clicking the IM Account Forwarding submenu, the Instant Messaging Account Forwarding Admin screen appears. In a new User Profile, there will be no ‘routes’ initially. As in Account creation, click the Add Route button to specify a new new route between an IM Account and another message Account. After clicking Add Route, a screen similar to Figure 4-10 will appear unless you don’t have any Accounts defined, in which case you will get an error screen (Figure 4-11). The top drop down list contains the list of IM Accounts shown with the format: screen name : message service provider. The bottom drop down list contains a list of non-IM Accounts that you can associate with the IM Account. This is true except for JBuddy accounts (JSC). This type of IM account will appear in the top list because it’s an IM account, however it will also be available as a choice in the bottom drop down list. When a JBuddy account is used in the top drop down list, then it can not be used in the bottom drop down list for that ‘route’. Instead a non-IM account can be used to forward JBuddy protocol messaging and presence to a non-IM gateway such as a mobile email account or even the JBuddy Instant Help software. If a JBuddy account is not used in the top drop down list, it can be used in the bottom drop down list. In this scenario, the top drop down list would be a public or enterprise IM and the messages and presence from this public or enterprise IM is forwarded when the JBuddy protocol client (JBuddy Messenger or a JBuddy SDK app such as an IM Bot) is online.
IM Forwarding To Blackberry (e-mail enabled devices)
Forwarding IM accounts to an SMTP account permits an end user to receive IM messages and buddy presence on an email enabled device such as a Blackberry phone or pager. If the routes have been created but not activated prior to leaving the office, the end user can login to the JBuddy Message Server Admin Console using a WAP enabled browser from the device if the end user has authorization credential to login and if the Admin Console is accessible from the device (see WAP Login in the Logging In section above). It should be noted that if IM logging has been enabled, that even messages to and from the mobile user will be logged ensuring full-time regulatory compliance even from the road.
IM Forwarding To Instant Help
Forwarding IM accounts to an Instant Help account permits an IM account to be used as a proxy representative for a real person. As an example, the ZionRep AIM account could be forwarded to an Instant Help account named ‘Sales’. When a properly configured Instant Help web link was clicked by a web visitor, the Sales Instant Help proxy would be selected and an IM help invitation would be sent to one or more real IM users through the proxy representative (ZionRep). This scenario is very powerful for distributed live help desk support and will be covered in a chapter of its own.
IM Forwarding To JBuddy Message Server Accounts
Forwarding public or enterprise IM accounts to JBuddy Message Server accounts is used for two scenarios typically:
1.Central control of public IM access. Define which IM accounts and which JBuddy Messenger Users will have access to external protocols. This is primarily when an end-user will be using the JBuddy Messenger / Pro IM client or another JBuddy-enabled IM client on their desktop. (Figure 1-2).
2.Central control and management of IM Bots made available on public IM networks. Bots are written using JBuddy IM toolkits and access the JBuddy Message Server using the JBuddy protocol (JSC) and are made available to public IM users by creating a route to forward public IM account(s) to the JBuddy-protocol connected IM Bot.
If the Enable Forwarding checkbox is checked, clicking OK will store the active state of this route in the database and the accounts will attempt to connect and go online. For scenario 2 detailed above, the routes state will be active but the IM account will not go online until a remote JBuddy client connects, at which time the route will be provisioned in the server and the IM account will attempt to go online and begin routing messages and presence to and from the public or enterprise IM client to the JBuddy client.
Figure 4-10: Instant Messaging Account Forwarding (create new route)
Figure 4-11: Instant Messaging Account Forwarding (error when no accounts exits)
After clicking OK in the Instant Messaging Account Forwarding (create new route) screen, you will return to the Instant Messaging Account Forwarding Admin screen. If Enable Forwarding was checked, the Action column will show a red stop sign (since clicking it would “stop” the enabled account forwarding). Since activating an account may take some time, the IM Status and Status columns may not refresh by themselves and may have a horizontal bar which normally indicates an offline status (Figure 4-12).
Figure 4-12: Forwarding an AIM account to a mobile email address
In this case, a newly enabled route just needs to be manually refreshed. This can be accomplished by clicking on either the IM Status or Status column headers to sort by that column. A side effect of sorting the column is that the statuses also refresh. If they are online, you will see a green bullet icon (Figure 4-13).
Figure 4-13: AIM Status (online), Mobile Email (online) after column sort
Returning to the IM Account Forwarding screen, we notice the new online accounts status as indicated by the status column with green (online) bullets (Figure 4-14). If a route was not active, instead of a stop sign, you would see a green “Go” button to indicate that you need to press GO to activate it.
DeActivating IM Forwarding
IM Forwarding can be deactivated simply by clicking on the red stop sign or deleting the route altogether. In addition, a mobile users with a WAP enabled browser and authorization credentials can login (see WAP Login in the Logging In section above) to the Admin Console if it’s accessible and de-active any active routes.
Figure 4-14 Account Manager Admin with account online status
In the next chapter, we will examine the Buddy Manager were the status of buddies is determined by the active, online status of accounts in this section.