ClearQuest Email Notification Package Delivery Mode - Revision history

Paul at 14:42, 1 February 2013

2013-02-01T14:42:12Z

Paul at 20:47, 19 August 2011

2011-08-19T20:47:03Z

Paul at 20:36, 19 August 2011

2011-08-19T20:36:17Z

Paul at 20:35, 19 August 2011

2011-08-19T20:35:56Z

Paul at 20:09, 19 August 2011

2011-08-19T20:09:14Z

Paul at 19:32, 19 August 2011

2011-08-19T19:32:41Z

Paul at 19:31, 19 August 2011

2011-08-19T19:31:16Z

Paul: Created page with "'''Delivery Mode''' Delivery Mode The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows t..."

2011-08-19T19:15:41Z

Created page with "<big>'''Delivery Mode'''</big> Delivery Mode The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows t..."

New page

<big>'''Delivery Mode'''</big>

Delivery Mode

The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows to unify configuration for all possible ClearQuest clients (Windows, Eclipse, UNIX, CCWeb), but requires a mail server, also called SMTP relay, to accept incoming messages either anonymously, or using some credentials for authentication. Usually, it is not a problem. Many tools employ SMTP, and your would not be first who approached system administrators asking for mail server configuration information in your organization. They should be able to assist you.

It does not mean that SMTP is the only mechanism that can be employed. SMTP is "out of the box" solution, but other protocols can be plugged in.

There are three main delivery modes supported by the package: Deferred (default), Light, and Queue. Delivery mode is controlled by '''EN_DeliveryMode''' database property.

== Deferred Delivery (default) ==
When no EN_Delivery mode property is set, or the property value is set to "Deferred," the package perform delivery in the following way.
[[File:Deferred_Delivery_1.png]]

When user is executing some action in ClearQuest, email rules are evaluated. All email messages created in result are stored in the ClearQuest database (1). A special stateless record type, en_email_message, a part of the package, is used to keep these messages. When rules evaluation is completed, the same ClearQuest client queries the database for all email messages that are eligible for delivery (2), and deliver them to the SMTP server (3). When message transfer is successful, these messages are accepted for further delivery to the recipients by the server.

It might be possible that SMTP server was not able to accept emails for delivery. For example, it could be down for maintenance, overloaded; connection could be blocked by firewall or internet security software installed on the user's machine.
[[File:Deferred_Delivery_2.png]]

In this case, these messages would be queried when action is performed by other ClearQuest client, at the end of its own rules evaluation cycle (4) to be delivered (5).

Maximum number of delivery attempts is 5, and can be changed by setting '''EN_DeliveryAttempt''' property. When maximum number of delivery attempts is reached, further delivery can be performed by ClearQuest administrator by executing '''Send Message''' action on the en_email_message records, or by resetting number of delivery attempts on them.

== Light Delivery ==

== Queue Delivery ==

== Other Considerations ==

== Custom Delivery Mechanisms ==

[[Category:ClearQuest]] [[Category:Email_Notification_Package]]

← Older revision		Revision as of 14:42, 1 February 2013
Line 49:		Line 49:


−	[[Category:ClearQuest]] [[Category:Email_Notification_Package]]	+
		+	[[Category:Rational]] [[Category:ClearQuest]] [[Category:Email_Notification_Package]]

@@ Line 2: / Line 2: @@
-The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows to unify configuration for all possible ClearQuest clients (Windows, Eclipse, UNIX, CCWeb), but requires a mail server, also called SMTP relay, to accept incoming messages either anonymously, or using some credentials for authentication. Usually, it is not a problem. Many tools employ SMTP, and your would not be first who approached system administrators asking for mail server configuration information in your organization. They should be able to assist you.
+The package was designed to use Simple Mail Transfer Protocol (SMTP) to deliver generated notification messages. SMTP allows to unify configuration for all ClearQuest clients (Windows, Eclipse, UNIX, CCWeb), but requires a mail server, also called SMTP relay, to accept incoming messages either anonymously, or using some credentials for authentication. Usually, it is not a problem. Many tools employ SMTP, and your would not be the first who approached system administrators asking for mail server configuration information in your organization. They should be able to assist you.
-It does not mean that SMTP is the only mechanism that can be employed. SMTP is "out of the box" solution, but other protocols can be plugged in.
+It does not mean that SMTP is the only mechanism that can be employed. SMTP is "out of the box" solution, but other protocols can be plugged in as well.
 There are three main delivery modes supported by the package: Deferred (default), Light, and Queue. Delivery mode is controlled by '''EN_DeliveryMode''' database property.
 == Deferred Delivery (default) ==
-When no EN_Delivery mode property is set, or the property value is set to "Deferred," the package perform delivery in the following way.
+When no EN_Delivery mode property is set, or the property value is set to "Deferred," the package performs delivery in the following way.
 [[File:Deferred_Delivery_1.png | center]]
-When user is executing some action in ClearQuest, email rules are evaluated. All email messages created in result are stored in the ClearQuest database (1). A special stateless record type, en_email_message, a part of the package, is used to keep these messages. When rules evaluation is completed, the same ClearQuest client queries the database for all email messages that are eligible for delivery (2), and deliver them to the SMTP server (3). When message transfer is successful, these messages are accepted for further delivery to the recipients by the server.
+When user is executing some action in ClearQuest, email rules are evaluated. All notifications created in result are stored in the ClearQuest database (1). A special stateless record type, en_email_message, a part of the package, is used to keep these messages. When rules evaluation is completed, the same ClearQuest client queries the database for all email messages that are eligible for delivery (2), and deliver them to the SMTP server (3). When message transfer is successful, these messages are accepted for further delivery to the recipients by the server.
 It might be possible that SMTP server was not able to accept emails for delivery. For example, it could be down for maintenance, overloaded; connection could be blocked by firewall or internet security software installed on the user's machine.
@@ Line 19: / Line 19: @@
 [[File:Deferred_Delivery_2.png | center ]]
-In this case, these messages would be queried when action is performed by other ClearQuest client, at the end of its own rules evaluation cycle (4) to be delivered (5).
+In this case, these messages would be queried when other action is performed later by the same or other ClearQuest client, at the end of rules evaluation cycle (4) and delivered (5).
 Maximum number of delivery attempts is 5, and can be changed by setting '''EN_DeliveryAttempt''' property. When maximum number of delivery attempts is reached, further delivery can be performed by ClearQuest administrator by executing '''Send Message''' action on the en_email_message records, or by resetting number of delivery attempts on them.
@@ Line 25: / Line 25: @@
 == Light Delivery ==
-When notification audit trail is not so important, and you would like to minimize interactions with database without sacrificing reliability, you can consider using '''Light''' delivery mode.
+When notification audit trail is not so important, and you would like to minimize interactions with the database without sacrificing reliability, you can consider using '''Light''' delivery mode.
 [[File:Light_Delivery.png | center]]
-In this case, generated email messages delivered immediately to the SMTP server (1), and only when the server is unavailable or delivery is blocked, the message will be dumped to the database (2) to be queried (3) and delivered (4) by the same or other client later.
+In this case, generated email messages delivered immediately to the SMTP server (1), and only when the server is unavailable or delivery is blocked, the messages will be dumped to the database (2) to be queried (3) and delivered (4) by the same or other client later.
 == Queue Delivery ==
@@ Line 38: / Line 38: @@
 In this case ClearQuest client would not perform delivery attempt. All created emails are dumped in the database (1). These messages needs to be queried by [http://cqadmin.org/wiki/Download delivery script] (2) running on the ClearQuest server(s). The only requirement for the server is to have ClearQuest installed and database connection configured. ClearQuest Web (CM) servers could be good candidates for scheduled execution of the script, and it might make sense to configure more than one for redundancy.
-Queue delivery might be extremely useful when sending emails from users' desktops is restricted by organization policy, blocked by security software, firewall, or fails due to application bugs (for example, in some versions ClearQuest 7.0 Eclipse client). It also improve end-user performance, in comparison with Deferred mode, as actions are not delayed while sending emails.
+Queue delivery might be extremely useful when sending emails from users' desktops is restricted by security policy, blocked by firewall, or fails due to application bugs (for example, socket library in some versions ClearQuest 7.0 Eclipse client). It also improves end-user performance, in comparison with Deferred mode, as actions are not delayed for sending emails.
 == Other Considerations ==
-Running delivery script on the server is required for Queue delivery mode, but might be useful with Deferred and Light modes as well. It would ensure timely message delivery even with no user activity.
+Running delivery script on the server is required for Queue delivery mode, but might be useful with Deferred and Light modes as well. It would ensure timely delivery of email even with no user activity on the database.
-Message queue, en_email_message table, has tendency to grow over the time. It is a good practice to periodically purge the table. A simple script can be found on [http://cqadmin.org/wiki/Download Downloads] page.
+Message queue, en_email_message table, has tendency to grow over the time. It is a good practice to purge the table periodically. A simple script can be found on [http://cqadmin.org/wiki/Download Downloads] page.
 == Custom Delivery Mechanisms ==
-SMTP along with offered delivery modes should be able to satisfy most of the requirements. Nevertheless, it might be required to employ custom delivery mechanism. Fortunately, Queue delivery mode opens this possibility. When Queue mode is used, Email Notification package would ensure that all generated messages are stored in the database, and you can implement desirable delivery protocol by taking simple delivery script as an example.
+SMTP along with offered delivery modes should satisfy most of the users' requirements, but sometimes, it might be required to employ custom delivery mechanisms. Fortunately, Queue delivery mode opens this possibility. When Queue mode is used, Email Notification package would ensure that all generated messages are stored in the database, and you can implement desirable delivery protocol by taking simple delivery script as an example and enhancing it.
 [[Category:ClearQuest]] [[Category:Email_Notification_Package]]

← Older revision		Revision as of 20:36, 19 August 2011
Line 1:		Line 1:
	<big>'''Delivery Mode'''</big>		<big>'''Delivery Mode'''</big>

−	~~Delivery Mode~~

	The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows to unify configuration for all possible ClearQuest clients (Windows, Eclipse, UNIX, CCWeb), but requires a mail server, also called SMTP relay, to accept incoming messages either anonymously, or using some credentials for authentication. Usually, it is not a problem. Many tools employ SMTP, and your would not be first who approached system administrators asking for mail server configuration information in your organization. They should be able to assist you.		The package was designed to use Simple Mail Transfer Protocol (SMTP) for delivery of generated notification messages. SMTP allows to unify configuration for all possible ClearQuest clients (Windows, Eclipse, UNIX, CCWeb), but requires a mail server, also called SMTP relay, to accept incoming messages either anonymously, or using some credentials for authentication. Usually, it is not a problem. Many tools employ SMTP, and your would not be first who approached system administrators asking for mail server configuration information in your organization. They should be able to assist you.

@@ Line 37: / Line 37: @@
 [[File:Queue_Delivery.png | center]]
-In this case ClearQuest client would not perform delivery attempt. All created emails are dumped in the database (1). These messages needs to be queried by [http://cqadmin.org/wiki/Download delivery script] (2) running on the ClearQuest server(s). We usually use ClearQuest Web (CM) server for scheduled execution of the script.
+In this case ClearQuest client would not perform delivery attempt. All created emails are dumped in the database (1). These messages needs to be queried by [http://cqadmin.org/wiki/Download delivery script] (2) running on the ClearQuest server(s). The only requirement for the server is to have ClearQuest installed and database connection configured. ClearQuest Web (CM) servers could be good candidates for scheduled execution of the script, and it might make sense to configure more than one for redundancy.
 Queue delivery might be extremely useful when sending emails from users' desktops is restricted by organization policy, blocked by security software, firewall, or fails due to application bugs (for example, in some versions ClearQuest 7.0 Eclipse client). It also improve end-user performance, in comparison with Deferred mode, as actions are not delayed while sending emails.
@@ Line 44: / Line 44: @@
 Running delivery script on the server is required for Queue delivery mode, but might be useful with Deferred and Light modes as well. It would ensure timely message delivery even with no user activity.
-Message queue, en_email_message table, has tendency to grow over the time. It is a good practice to periodically purge the table.
+Message queue, en_email_message table, has tendency to grow over the time. It is a good practice to periodically purge the table. A simple script can be found on [http://cqadmin.org/wiki/Download Downloads] page.
 == Custom Delivery Mechanisms ==
 [[Category:ClearQuest]] [[Category:Email_Notification_Package]]

@@ Line 28: / Line 28: @@
 When notification audit trail is not so important, and you would like to minimize interactions with database without sacrificing reliability, you can consider using '''Light''' delivery mode.
-[[File:Light_Delivery.jpg | center]]
+[[File:Light_Delivery.png | center]]
-In this case, generated email messages delivered immediately to the SMTP server (1), and only when the server is unavailable or delivery is blocked, the message will be dumped to the database to be queried (2) and delivered (3) by the same or other client later.
+In this case, generated email messages delivered immediately to the SMTP server (1), and only when the server is unavailable or delivery is blocked, the message will be dumped to the database (2) to be queried (3) and delivered (4) by the same or other client later.
 == Queue Delivery ==