Index Changes

Difference between version and version     

Back to SMTPBC Requirements And Use Cases, or SMTPBC Requirements And Use Cases Info


At line 11 changed 1 line.
| S-4 | Full Junit tests for all classes | | P1
| S-4 | Full Junit tests for all classes | Kenai | P1
At line 50 changed 2 lines.
| RT-4 | Add “From” attribute in extensibility elements | Kenai | P1
| RT-5 | Support for multiple recipients, bcc, and cc lists |Kenai | P1
| RT-4 | Add “From” attribute in extensibility elements. Ability to dynamically specify the “From” email id in the runtime. | Kenai | P1
| RT-5 | Support for multiple recipients, bcc, and cc lists. Ability to send emails to multiple recipients specifying bcc and cc lists in the mailto URL. Also in the Inbound scenario, accept emails which are in cc and bcc lists. |Kenai | P1
| RT-6 | Support for HTML Formatted messages. Ability to send and receive HTML formatted messages. | | P2
| RT-7 | Sending Undeliverable mail messages. Sending delivery status failure notification emails. | | P2
| RT-8 | Configurable SMTP Port. The ability for a user to configure the port on which the SMTP server has to run. | Kenai | P1
| RT-9 | Encoding Support. Support for encoders using “use” and encodingStyle Attribute. Support for custom encoder. | Kenai | P1
| RT-10 | Ability to connect to external SMTP servers which requires authentication and SSL. | Kenai | P1
| RT-11 | Ability to specify the email ids in “to”, “cc” and “bcc” list in the runtime. | Kenai | P1
At line 59 added 3 lines.
At line 59 changed 1 line.
| Use Case Name | __Adding individual SMTP Extensibility elements to a WSDL__ \\ The “Adding individual SMTP Extensibility elements to a WSDL” Use Case describes a scenario where individual extensibility elements are added to a WSDL document through the WSDL Editor. (Screenshots will be attached at a later date)
| Use Case Name | __Adding individual SMTP Extensibility elements to a WSDL__ \\ The “Adding individual SMTP Extensibility elements to a WSDL” Use Case describes a scenario where individual extensibility elements are added to a WSDL document through the WSDL Editor. (Screenshots will be attached at a later date)
At line 62 changed 1 line.
| Normal Flow | 1. Create a new Binding Element from the root node.. \\ 2. For this new Binding Element add a “SMTP Binding Element”. \\ 3. Associate the Binding Element with a PortType. \\ 4. Add a Binding Operation for the Binding Element. \\ 5. For the new Binding Operation, add a “SMTP Binding Operation”. \\ 6. On the Input node for the new Binding Operation, add a new “SMTP Message”. \\ 7. Create a new Service Element from the root node. \\ 8. Create a new Port element from the Service element. \\ 9. Add a SOAP Address element.
| Normal Flow | 1. Create a new Binding Element from the root node.. \\ 2. For this new Binding Element add a “SMTP Binding Element”. \\ 3. Associate the Binding Element with a PortType. \\ 4. Add a Binding Operation for the Binding Element. \\ 5. For the new Binding Operation, add a “SMTP Binding Operation”. \\ 6. On the Input node for the new Binding Operation, add a new “SMTP Message”. \\ 7. Create a new Service Element from the root node. \\ 8. Create a new Port element from the Service element. \\ 9. Add a SOAP Address element.
At line 71 changed 1 line.
| Use Case Name | __Adding a SMTP template to a WSDL__ \\ The “Adding a SMTP template to a WSDL” Use Case describes a scenario where the wizard assists the user in generating SMTP Extensibility Elements.
| Use Case Name | __Adding a SMTP template to a WSDL__ \\ The “Adding a SMTP template to a WSDL” Use Case describes a scenario where the wizard assists the user in generating SMTP Extensibility Elements.
At line 84 changed 1 line.
| Use Case Name | __Validating SMTP Extensibility Elements in the WSDL Editor__ \\ The “Validating SMTP Extensibility Elements in the WSDL Editor” Use Case describes a scenario where validation of SMTP Extensibility Elements is invoked from the WSDL Editor.
| Use Case Name | __Validating SMTP Extensibility Elements in the WSDL Editor__ \\ The “Validating SMTP Extensibility Elements in the WSDL Editor” Use Case describes a scenario where validation of SMTP Extensibility Elements is invoked from the WSDL Editor.
At line 87 changed 1 line.
| Normal Flow | 1. Click on the validate button in the WSDL Editor tool bar. \\ 2. On the WSDL file in the Project explorer, right-click to bring up the menu. \\ 3. Click on the “Validate XML” option.
| Normal Flow | 1. Click on the validate button in the WSDL Editor tool bar. \\ 2. On the WSDL file in the Project explorer, right-click to bring up the menu. \\ 3. Click on the “Validate XML” option.
At line 99 changed 1 line.
| Normal Flow | 1. This use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete HTTP SOAP binding so the client must use SOAP over HTTP to properly invoke the operation. \\ 2. The HTTP Binding Component receives the message, converts it from the SOAP message to a Normalized Message, and forwards the Normalized Message through the Normalized Message Router (NMR) to the awaiting BPEL process. \\ 3. The BPEL process receives the message for the abstract operation and then invokes a different In-Only abstract operation. This abstract operation has a concrete SMTP binding. \\ 4. When the BPEL process invokes the abstract operation, a Normalized Message is generated and sent to the NMR. \\ 5. The SMTP Binding Component picks up the Normalized Message, converts it to a proper SMTP message, and sends it to an SMTP server that will process the request. The SMTP message will contain at minimum the “To” address.
| Normal Flow | 1. This use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete HTTP SOAP binding so the client must use SOAP over HTTP to properly invoke the operation. \\ 2. The HTTP Binding Component receives the message, converts it from the SOAP message to a Normalized Message, and forwards the Normalized Message through the Normalized Message Router (NMR) to the awaiting BPEL process. \\ 3. The BPEL process receives the message for the abstract operation and then invokes a different In-Only abstract operation. This abstract operation has a concrete SMTP binding. \\ 4. When the BPEL process invokes the abstract operation, a Normalized Message is gener
2000
ated and sent to the NMR. \\ 5. The SMTP Binding Component picks up the Normalized Message, converts it to a proper SMTP message, and sends it to an SMTP server that will process the request. The SMTP message will contain at minimum the “To” address.
At line 101 changed 1 line.
| Post Condition | A mail message should appear at the account specified by the “To” address in the SMTP message
| Post Condition | A mail message should appear at the account specified by the “To” address in the SMTP message
At line 111 changed 1 line.
| Normal Flow | 1. The use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete SMTP binding so the client must use the SMTP protocol to properly invoke the operation. \\ 2. The SMTP Binding Component receives the SMTP Message (which must have at minimum the “To” field populated). \\ 3. The SMTP Binding Component converts the SMTP Message to a Normalized message and sends it to the NMR. \\ 4. A BPEL process being handled by the BPEL Service Engine handles the abstract message, and returns a status message of either DONE or ERROR. \\ 5. Based on the status message, the SMTP BC returns the proper message to the web service client.
| Normal Flow | 1. The use case begins with a web service client invoking an In-Only abstract operation implemented by a BPEL process. The abstract operation has a concrete SMTP binding so the client must use the SMTP protocol to properly invoke the operation. \\ 2. The SMTP Binding Component receives the SMTP Message (which must have at minimum the “To” field populated). \\ 3. The SMTP Binding Component converts the SMTP Message to a Normalized message and sends it to the NMR. \\ 4. A BPEL process being handled by the BPEL Service Engine handles the abstract message, and returns a status message of either DONE or ERROR. \\ 5. Based on the status message, the SMTP BC returns the proper message to the web service client.
At line 120 changed 1 line.
| Use Case Name | __SMTP Address with the “mailto:” URL__ \\ The “SMTP Address with the “mailto:” URL” Use Case describes a scenario where the location attribute of the <smtp:address> is set to variations of the mailto URL scheme.
| Use Case Name | __SMTP Address with the “mailto:” URL__ \\ The “SMTP Address with the “mailto:” URL” Use Case describes a scenario where the location attribute of the <smtp:address> is set to variations of the mailto URL scheme.
At line 132 changed 1 line.
| Use Case Name | __SMTP “From”, “Subject”, and “Message” Attribute__ \\ The “SMTP “From”, “Subject”, and “Message” Attribute” Use Case describes a scenario where any combination of these attributes are present in an underlying SMTP Message when invoking or implementing a web service that uses SMTP as the transport mechanism.
| Use Case Name | __SMTP “From”, “Subject”, and “Message” Attribute__ \\ The “SMTP “From”, “Subject”, and “Message” Attribute” Use Case describes a scenario where any combination of these attributes are present in an underlying SMTP Message when invoking or implementing a web service that uses SMTP as the transport mechanism.
At line 144 changed 1 line.
| Use Case Name | __SMTP Support for multiple recipients through “bcc” and “cc”__ \\ The “SMTP Support for multiple recipients through “bcc” and “cc”” Use Case describes a scenario where a single message is sent to multiple recipients. If we view SMTP as a transport mechanism for abstract messages, then each recipient may be seen as a different channel for which to send messages.
| Use Case Name | __SMTP Support for multiple recipients through “bcc” and “cc”__ \\ The “SMTP Support for multiple recipients through “bcc” and “cc”” Use Case describes a scenario where a single message is sent to multiple recipients. If we view SMTP as a transport mechanism for abstract messages, then each recipient may be seen as a different channel for which to send messages.
At line 163 added 74 lines.
%%
%%
|| ID || RT-UC-6
| Use Case Name | __Support for HTML Formatted email__ \\ This usecase is similar to the SMTP Outbound scenario only with the difference that the content of the soap message is a HTML text.
| Requirements Addressed | RT-6
| Pre Condition | A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete HTTP/SOAP Binding. The BPEL invokes a web service operation with a concrete SMTP Binding
| Normal Flow | The usecase is equivalent to RT-UC-1. The input message for this usecase should be a HTML formatted text.
| Exception Flow |
| Post Condition | A mail message should appear at the account specified by the “To” address in the SMTP message. The content of the mail should be formatted according to the HTML format of the input.
%%
%%
%%
%%
|| ID || RT-UC-7
| Use Case Name | __Sending delivery status failure notification emails__ \\ This usecase is similar to the SMTP Outbound scenario. If the sending of the mail fails because of some reason, a delivery status notificaton email should be sent to the email Id specified in the email address.
| Requirements Addressed | RT-7
| Pre Condition | A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete HTTP/SOAP Binding. The BPEL invokes a web service operation with a concrete SMTP Binding.
| Normal Flow | The usecase is equivalent to RT-UC-1. If the SMTP BC finds that there is some error in sending email to any one of the destination specified in “to”, “cc” or “bcc” list, a delivery status notification email should be sent to the email id specified in “from” address.
| Exception Flow |
| Post Condition | A delivery status notification mail should appear in the mail box of the from email address with the reason for not delivering and the email ids failed.
%%
%%
%%
%%
|| ID || RT-UC-8
| Use Case Name | __Configurable SMTP Port__ \\ The User should be able to specify the port on which the SMTP BC's SMTP Server should listen.
| Requirements Addressed | RT-8
| Pre Condition | The WSDL of the SMTP Binding component should have the port no specified in “port” attribute of the <smtp:address” tag.
| Normal Flow | 1. Create a BPEL module project with SMTP BC and File BC for an inbound scenario. \\2. Deploy the project in the App. Server and start the Service Assembly.
| Exception Flow | The SMTP Server should not start if the port is busy.
| Post Condition | The SMTP BC's SMTP Server should listen on the port mentioned by the user instead of the default port “25”.
%%
%%
%%
%%
|| ID || RT-UC-9
| Use Case Name | __Encoder support__ \\ The SMTP BC should be able to encode and decode the email message according to the “encodingStyle” specified in the wsdl extension.
| Requirements Addressed | RT-9
| Pre Condition | The WSDL of the SMTP Binding component should have use=”encoded” and encodingStyle=”<encoder module name>” specified.
| Normal Flow | Inbound Scenario : The BC should be able to decode the message according to the encoding style and pass the normalized message to the NMR. \\ Outb
2000
ound Scenario: The BC should be able to encode the message according to the encoding style and send the email to its destination.
| Exception Flow | An error message should appear in the log if the encodingStyle specified is not supported or unknown.
| Post Condition | Inbound Scenario: The NMR should receive the decoded form of the email. \\ Outbound Scenario: The email message should appear encoded in the mail box.
%%
%%
%%
%%
|| ID || RT-UC-10
| Use Case Name | __Ability to connect to external SMTP Servers which require authentication and SSL.__ \\ The User should be able to provide authentication information such as username , password and ssl port for connecting to SMTP Servers which require authentication and ssl. The SMTP BC should be able to connect to such servers and send e-mails.
| Requirements Addressed | RT-10
| Pre Condition | A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete HTTP/SOAP Binding. The BPEL invokes a web service operation with a concrete SMTP Binding. The user should have provided username and password and useSSL=”true” in the WSDL extensibility elements.
| Normal Flow | The flow is the same as SMTP Outbound Scenario.
| Exception Flow |
| Post Condition | A mail message should appear at the account specified by the “To” address in the SMTP message.
%%
%%
%%
%%
|| ID || RT-UC-11
| Use Case Name | __Ability to specify the email ids in “to”, “cc” and “bcc” list in the runtime.__ \\ The user uses bpel mapper to specify the email ids in “to”, “cc” and “bcc” attributes. The SMTP Binding component should be able to parse the message part in those attributes and send emails to those Ids.
| Requirements Addressed | RT-11
| Pre Condition | A deployed BPEL project with a BPEL that is triggered by a web service client using a concrete HTTP/SOAP Binding. The BPEL invokes a web service operation with a concrete SMTP Binding. \\ The User should have “to”,”cc” and “bcc” attributes in the <smtp:input> tag and the values of those attributes should evaluate to valid comma separated email ids in the runtime.
| Normal Flow | The flow is the same as SMTP Outbound Scenario.
| Exception Flow |
| Post Condition | A mail message should appear at the account specified by the “to” , “cc” and “bcc” addresses.
%%
%%

JSPWiki v2.4.100
[RSS]
« Home Index Changes Prefs
This page (revision-37) was last changed on 01-Oct-07 12:28 PM, -0700 by MarkWhite