DIRECTORATE-GENERAL
INFORMATICS
Information Systems Directorate
European Commission
CIPADMIN Use Case Specification:
UC0140 - e-TrustEx Admin Console - Inspect Messages
Date: / 25/01/201714/06/2015Version: / 21.000005
Authors: / Anamaria BATRINU, Yves ADAM
Revised by: / Olivier DERVEAU, Cristian CHIRIAC, Anamaria BATRINU
Approved by:
Public:
Reference Number:
TABLE OF CONTENTS
1. Use-Case Description
1.1. Primary Actor
1.2. Definitions, Acronyms and Abbreviations
1.3. References
1.4. Context Diagram
1.4.1. CIPA Administration Console
1.4.2. Inspect Messages module
2. Flow of events
2.1. Basic Flow
2.1.1. User wants to inspect specific messages
2.1.2. System displays the "Messages" page
2.1.3. User enters the message criteria
2.1.4. The System searches the messages
2.1.5. System displays the messages found
2.1.6. User views the result list
2.1.7. The basic search flow ends.
2.2. Alternate Flows
2.2.1. A1: At step 2.1.6, User wants to inspect the message details of a Message in the list
2.2.2. A2: At step 2.1.6, User wants to search for other message(s)
2.2.3. A3: at step 2.1.3, User chooses to search for an Issuer, a Sender or a Receiver
2.2.4. A4: at step 2.1.3, User chooses to search for an Interchange Agreement
2.2.5. A5: at step 2.1.3, User chooses to search for a Transaction
2.2.6. A6: at step 2.1.4, no message found for the specified criteria
2.3. Subflows
2.3.1. S1: User wants to view Issuer, Sender, Receiver, Transaction or Interchange Agreement details
2.3.2. S2: User wants to see Message Binaries information
2.3.3. S3: User wants to see Message Routing information
2.3.4. S4: User wants to see Parent Messages or Child Messages
2.3.5. S5: User wants to resubmit the message to the asynchronous processing queue
2.3.6. S6: User wants to redispatch the message to one of the configured routing endpoints
2.4. Exceptional Flows
2.4.1. E1: at steps 2.1.1 or 2.2.1 User is not authorized for the operation
2.4.2. E2: at any step, a technical error occurs
2.4.3. E3: at step 2.1.4, Business Rules are not verified
2.4.4. E4: User is not authorised for resubmitting (subflow S5) or redispatching (subflow S6) the message
2.4.5. E7: Business Rules are not verified for resubmit or redispatch subflows
2.4.6. E6: An error occurs in the resubmit or redispatch subflows, and the message does not reach the corresponding queue
3. Special Requirements
3.1. Interface(s) with other Systems
3.2. Security Requirements
3.3. Other Special Requirement
4. Preconditions
5. Post conditions
6. Additional Information
6.1. Includes
6.2. Extends
7. Mock-up screens
7.1. "Messages" page
7.2. "Message Details" page
7.2.1. Message Resubmission Confirmation
7.2.2. Message Resubmission Notification
7.3. "Message binaries" popup
7.4. "Routing information" popup
7.4.1. Message Redispatching Confirmation
7.4.2. Message Redispatching Notification
7.5. "Child messages" popup
7.6. "Parent messages" popup
Document History
Version / Date / Comment / Modified Pages1.000 / 23/03/2015 / First version / All
1.001 / 10/05/2016 / Add possibilities to resend messages
1.002 / 27/05/2016 / Review of changes made for message processing retry and redispatching
1.003 / 06/06/2016 / Review & update conform to JIRA ETRUSTEX-1412: Allowing reprocessing of messages: user shall be able to resend messages in state SUBMITTED to the asynchronous processing queue. Added also messages in state ERROR.
Review & update conform to JIRA ETRUSTEX-1399: Allowing resending of messages in the dispatching queue: user shall be able to resend messages in state RECEIVED to the routing queue.
JIRA ETRUSTEX-1403: showing last dispatch date in the message routing information screen. Time will also be shown.
Bonus: Column Endpoint in the message routing information screen will not show the endpoint id anymore, but the webservice URL for webservice endpoints, and provider URL + destination queue for JMS endpoints.
1.004 / 14/06/2016 / Added detailed information about the JMS message to be sent to the routing queue (scenario 2.3.6.S6)
1.005 / 19/09/2016 / JIRA ETRUSTEX-1626 Messages should not be dispatched to an inactive endpoint. / Sections S6: User wants to redispatch the message to one of the configured routing endpoints, "Routing information" popup
1.006 / 17/10/2016 / Mentionned AMQP endpoint in the "Routing information" popup
Added in depth limitation for the child/parent details that can be seen from the message details
1.007 / 26/10/2016 / JIRA ETRUSTEX-1392 / Where needed
1.008 / 15/12/2016 / Excluded wrappers messages from resubmission to asynchronous processing / Section 2.3.5 S5: User wants to resubmit the message to the asynchronous processing queue
2.000 / 25/01/2017 / ETRUSTEX-1937: Reorganizing CIPAdmin user roles
2.001 / 14/03/2017 / ETRUSTEX-2185: Setting message priority when submitting to the asynchronous processing queue
1.Use-Case Description
This use case depicts the sequence of actions that a user needs in order to inspect Messages. In order to inspect a Message the user needs to search for it and to visualize the message details, its routing configurations and routing status, the messages parents and infants.
The "Inspect Message" service is exposed on the CIPAdmin module of e-Trustex platform.
In the remainder of the document the CIPADMIN application will be referred to as the System.
1.1.Primary Actor
A human user can access the Inspect Message feature via CIPAdmin interface. This feature is accessible only by users having General Administrator and Support role. For detailed user access rights on each feature option, please see UC 0100 - eTrustEx Admin Console - Authenticate and Authorise User, section 6.3 User Access Rights.
In the remainder of the document, the user will be refered to as User.
1.2.Definitions, Acronyms and Abbreviations
Acronym, Abbreviation or Definition / ExplanationCIPA / Common Infrastructure for Public Administrations
CIPADMIN / CIPA AdminConsole
ADM / A user having General Administrator role. The General Administrator is the Administrator of the CIPAdmin application.
UC(s) / Use Case(s)
1.3.References
Ref. / Reference / Title / description / Version / Date[R1] / CIPADMIN-VISION / CIPADMIN Visiondocument / V.61-EN / 18/04/2013
1.4.Context Diagram
1.4.1.CIPA Administration Console
The diagram below depicts all the Services available on the CIPA Administration Console for e-TrustEx platform. Depending on the user role, only a subset of those services is exposed on the e-TrustEx Administration Console home page.
1.4.2.Inspect Messages module
The diagram below depicts how this use case interacts with other use cases implemented in the Administration Console.
2.Flow of events
The conventions described in User Interface Generic Conventions document must be applied.
1.5.2.1.BasicFlow
1.5.1.2.1.1.User wants toinspect specific messages
ID / DescriptionUC140_BR01 / User needs to have the correct access rights in order to access this feature. Please see UC 0100 - eTrustEx Admin Console - Authenticate and Authorise User, section 6.3 User Access Rights for more information.
User selects the Messages option of the Inspect Monitoring and SUpport menu of the e-TrustEx Administration Console home page.
1.5.2.2.1.2.System displays the "Messages" page
System displays the search page as described in paragraph 7.2. "Messages" page.
1.5.3.2.1.3.User enters the message criteria
(1)Userenters one or more search criteria to identify the messages to inspect.
(2)User activates the search button.
1.5.4.2.1.4.The System searches the messages
ID / DescriptionUC140_BR02 / Business domain needs to be one of the business domains user is authorised to use.
UC140_BR03 / Business domain All value means that the messages will be searched within all business domains user is authorised to use.
UC140_BR04 / Creation period: from date must be less than or equal to to date.
UC140_BR05 / Issuer, Sender and Receiver, when specified:
- need to pertain to the business domain criteria selected
- need to pertain to one of the business domains user is authorised to use, if All option is selected in the business domain criteria
UC140_BR06 / Creation user, Correlation Id and Document Id can contain partial match.
UC140_BR07 / A field left empty or containing only spaces is not taken into account during the search.
UC140_BR08 / Character case is ignored.
UC140_BR09 / Trailing and leading spaces are ignored.
UC140_BR10 / Field value can contain a partial match for free text input fields.
UC140_BR11 / At least one search field should be filled in.
UC140_BR12 / If a single search field is filled in, it needs to contain at least 2 characters.
The system verifies the business rules and searches the messages that satisfy all the entered criteria.
1.5.5.2.1.5.System displays the messages found
The system displays the list of messagescoresponding to the search criteria, ordered by creation time showing the messages from the latest to the oldest. The messages with status code ERROR will be shown in red to allow a faster identification of messages in error.
1.5.6.2.1.6.User views the result list
At this point user can choose one of the following options:
(1)Choose the message to inspect by clicking on it in the result list (see section2.2.1 of Alternate Flows)
(2)Launcha new search
(3)Abandon the flow by choosing any other option in the System's menu
1.5.7.2.1.7.The basic search flow ends.
1.6.2.2.Alternate Flows
1.6.1.2.2.1.A1: At step2.1.6, User wants to inspect the message details of aMessage in the list
ID / DescriptionUC140_BR01 / User needs to have the correct access rights in order to access this feature. Please see UC 0100 - eTrustEx Admin Console - Authenticate and Authorise User, section 6.3 User Access Rights for more information.
(1)User selects the message he/she wants to inspect by clicking on it
(2)System opens a window containing the detailed information as described in paragraph 7.2"Message Details" page
(3)User inspects the message details. Additionally, User may inspect
- Message Issuer, Sender, Receiver, Transaction or Interchange Agreement details – include subflow2.3.1S1: User wants to view Issuer, Sender, Receiver, Transaction or Interchange Agreement details
- Message Binaries information – include subflow2.3.2User wants to see Message Binaries information
- Message Routing information – include subflow2.3.3S3: User wants to see Message Routing information
- Parent messages or Child messages – include subflow2.3.4S4: User wants to see Parent Messages or Child Messages
(4)User can resubmit the message (if it is not a wrapper message) to the asynchronous processing queue, if the message state is SUBMITTED or ERROR(seesubflowS5: User wants to resubmit the message to the asynchronous processing queue)
(5)User chooses to go back to the message list
(6)System closes the window
(7)Alternate flow ends and basic flow continues from 2.1.6
1.6.2.2.2.2.A2: At step 2.1.6, User wants to search for other message(s)
(1)User clears the current criteria fields
(2)Alternate flow ends and basic flow continues from step 2.1.3User enters the message criteria
1.6.3.2.2.3.A3: at step 2.1.3, User chooses to search for an Issuer, a Sender or a Receiver
(1)System opens a Party Search Popup: include section 2.2. Basic Search Flow (from step 2.2.2. System displays the Search Party page) of Manage Party Use Case.
(2)System retains the party id and fills in the corresponding read-only input text with the party name of the party returned at previous step
(3)Alternate flow ends and basic flow continues at 2.1.3.
1.6.4.2.2.4.A4: at step 2.1.3, User chooses to search for an Interchange Agreement
(1)System opens an Interchange Agreement Search Popup: include section 2.3. Basic Search Flow (from step 2.3.2. System displays the Search Interchange Agreement page) of Manage Interchange Agreement Use Case.
(2)System fills in the read-only input text with the interchange agreement id of the interchange agreement returned at previous step
(3)Alternate flow ends and basic flow continues at 2.1.3.
1.6.5.2.2.5.A5: at step 2.1.3, User chooses to search for a Transaction
(1)System opens a Transaction Search Popup: include section 2.3. Basic Search Flow (from step 2.2.2. System displays the Search Transaction page) of Manage Transaction Use Case.
(2)System fills in the read-only input text with the transaction name and version of the transaction returned at previous step
(3)Alternate flow ends and basic flow continues at 2.1.3.
1.6.6.2.2.6.A6: at step 2.1.4, no message found for the specified criteria
(1)System logs the error: include use case Log CIPAdmin User Actions
(2)The system notifies the user that no document has been found
(3)Alternate flow ends and basic search flow restarts at 2.1.3
1.7.2.3.Subflows
1.7.1.2.3.1.S1: User wants to view Issuer, Sender, Receiver, Transaction or Interchange Agreement details
(1)User chooses View option next to the information to vizualize
(2)System opens a View Popup showing the details of the concerned intormation:
Information type / Section to include / Start step / UCIssuer, Sender or Receiver / 2.3. Basic Visualization Flow / 2.3.2. System opens the "Party Visualization" page / Manage Party Use Case
Interchange Agreement / 2.4. Basic Visualization Flow / 2.4.2. System opens the "Interchange Agreement Visualization" page / Manage Interchange Agreement Use Case
Transaction / 2.3. Basic Visualization Flow / 2.3.2. System opens the transaction visualization page / Manage Transaction Use Case
1.7.2.2.3.2.S2: User wants to see Message Binaries information
(1)User activates Message binaries button
(2)System opens a window containing the message binaries information as described in paragraph 7.3"Message binaries" popup
(3)User views the details of the binaries corresponding to the message
(4)User activates the Cancelbutton in order to go back to the message details
(5)System closes the window
(6)User is back to the message details page
1.7.3.2.3.3.S3: User wants to see Message Routing information
(1)User activates Routing information button
(2)System opens a window containing the message routing information as described in paragraph 7.4"Routing information" popup
(3)User views the endpoints configured for the message, the status of the dispatching, the date and hour of the last dispatch (where it is the case)
- User can click on one of the endpoints in the list to see more details about the endpoint (include section 2.3. Basic visualization flow from step 2.3.2 System opens the Endpoint Configuration visualization page in Manage Endpoint Configurations Use Case)
- If the message is in state RECEIVED, user can redispatchit to any of the endpoints in the list (see subflowS6: User wants to redispatch the message to one of the configured routing endpoints)
(4)User activates the Cancelbutton in order to go back to the message details
(5)System closes the window
(6)User is back to the message details page
1.7.4.2.3.4.S4: User wants to see Parent Messages or Child Messages
(1)User activates Show parent messages or Show child messages button
(2)System opens a window containing the parent or child messages depending on the user selection as described in paragraphs 7.6"Parent messages" popup and 7.5"Child messages" popup respectively
(3)User views the parent/child messages
- User can click on one of the parent/child messages in the list to inspect it (see 2.2.1A1: At step 2.1.6, User wants to inspect the message details of a Message in the list)
(4)User activates the Cancelbutton in order to go back to the message details
(5)System closes the window
(6)User is back to the message details page
1.7.5.2.3.5.S5: User wants to resubmit the message to the asynchronous processing queue
ID / DescriptionUC140_BR01 / User needs to have the correct access rights (ADM) in order to access this feature. Please see UC 0100 - eTrustEx Admin Console - Authenticate and Authorise User, section 6.3 User Access Rights for more information.
UC140_BR17 / Wrapper messages shall not be subject to resubmission.
Note: We know if a message is a wrapper message if the transaction referred in the message corresponds to a Store Document Wrapper transaction.
UC140_BR13 / Only messages in state SUBMITTED or ERROR can be resubmitted.
(1)User activates the Resubmit button
(2)System asks confirmation (see section Message Resubmission Confirmation)
(3)User confirms by clicking on the "YES" button (if user chooses No, System closes the confirmation window and returns to the message details screen)
(4)System verifies the business rules
(5)System puts back the message on the asynchronous processing queue using the configured priority as specified in UC1_020 Retrieve and Set Message Priority.Additional information out of the scope of this use case: once in the asynchronous processing queue, the message will be handled as described in section3.1.3 System performs Asynchronous flow of Process Asynchronous Message UC.
(6)System creates a log record for this event
(7)System informs user that the message has been successfully placed in the queue (see section Message Resubmission Notification)
(8)User acknowledges
(9)System redisplays the message details screen
(10)Subflow ends
1.7.6.2.3.6.S6: User wants to redispatch the message to one of the configured routing endpoints
ID / DescriptionUC140_BR01 / User needs to have the correct access rights (ADM) in order to access this feature. Please see UC 0100 - eTrustEx Admin Console - Authenticate and Authorise User, section 6.3 User Access Rights for more information.
UC140_BR14 / Only messages in state RECEIVED can be redispatched.
UC140_BR15 / A message may be dispatched to any of its configured routing endpoints, and that even in the case it has already been dispatched (Dispatched = Yes).
UC140_BR16 / If the endpoint is inactive, no message can be dispatched to it. The Redispatch button shall not be displayed.
(1)User activates the Redispatch button corresponding to the endpoint to which the message should be redispatched
(2)System asks confirmation (see section Message Redispatching Confirmation)
(3)User confirms by clicking on the "YES" button (if user chooses No, System closes the confirmation window and returns to the routing information screen)
(4)System verifies the business rules
(5)System creates the corresponding JMS message containing the message endpoint association (represented by the idcorresponding to the line on which the Redispatch action was triggered)
(6)System sends the JMS message to the routing queue.
The JMS message will contain the following properties of the message to be re-dispatched:
- message id
- message document id
- issuer, sender, receiver ID
- ICA id
- document version
- transaction id
- transaction namespace
- transaction request local name
- log correlation id
- issuer username
- the message routing record id
Additional information out of the scope of this use case: once in the routing queue, the message will be handled as described in section 2.2 Retrieve message endpoint association and dispatch message of Dispatch Message UC.
(7)System creates a log record for this event
(8)System informs the user that the message has been sent for redispatching (see section Message Redispatching Notification)
(9)User acknowledges
(10)System redisplays the message routing information screen
(11)Subflow ends
1.8.2.4.Exceptional Flows
Any exception happening in the steps pertaining to other use cases that are called in this use case, are managed conform to their respective use case.
1.8.1.2.4.1.E1: at steps 2.1.1 or 2.2.1 User is not authorized for the operation
Include the steps in section 2.4.1 of Authenticate and Authorise User Use Case.