| Oracle® Retail Integration Cloud Service Java Messaging Service Console Guide Release 19.1.000 F32093-01 |
|
 Previous |
 Next |
| Oracle® Retail Integration Cloud Service Java Messaging Service Console Guide Release 19.1.000 F32093-01 |
|
Previous |
Next |
The Oracle Retail Java Messaging Service (JMS) Console is a Web application for monitoring, browsing, and managing the messages that flow through a JMS system. This application is designed for the Oracle Streams Advanced Queuing (AQ) JMS provider.
Monitor - provide an unattended view of JMS server.
Browse - discover and drill down into the various aspects of JMS server.
Manage - operate JMS server functionality.
JMS Console is intended for JMS administrators who want to monitor the health of the application and troubleshoot issues related to JMS system. Administrators can monitor the overall health of the system, browse and manage messages of a specific topic/subscriber as well as publish messages for a specific topic.
JMS Console is a very useful application to monitor and manage the AQ JMS regularly. It can troubleshoot critical issues related to any message blockages on the AQ JMS system as well as the Retail Integration Bus (RIB) messaging system which uses AQ as JMS provider.
Install JMS Console application only after the core RIB components have been installed and verified. Oracle recommends that you use JMS Console to monitor, manage, and troubleshoot the RIB AQ system.
Currently, there are no lightweight JMS administration tools available for the Oracle AQ. Generic JMS tools offer limited functionalities for the AQ JMS. JMS Console intends to fill this gap. Following are some key problem statements that JMS Console is expected to solve:
JMS servers do not provide visibility into their internal working and state.
Messages from JMS servers are not visible to the RIB system administrators until business is adversely impacted.
Third party systems are not able to publish messages to JMS, and in turn are not visible to the RIB, until it is too late.
Errors in JMS topics are not identified easily.
You cannot view incorrect messages that exist inside JMS servers.
Missing current or historical metrics data in messages.
Expose valuable business data from inside JMS server as services.
Following are JMS concepts:
Oracle Streams AQ JMS
RIB on AQ JMS
Oracle Streams Advanced Queuing (AQ) provides database-integrated message queuing functionality. It is built on Oracle Streams and leverages the functions of the Oracle database so that messages can be stored persistently, propagated between queues on different computers and databases, and transmitted using Oracle Net Services and HTTP(s).
Because Oracle Streams Advanced Queuing is implemented in database tables, all operational benefits of high availability, scalability, and reliability are also applicable to queue data. Standard database features such as recovery, restart, and security are supported by Oracle Streams AQ.
Oracle Streams AQ provides the PL/SQL APIs to interact with the native AQ server inside the Oracle database. The native AQ stream is not the same as the AQ behaving as a JMS server.
|
Note: For more information, see the Oracle® Database Administrator Guide 12c Release and the Oracle® Streams Advance Queuing User Guide. |
The RIB is a messaging application that uses Oracle AQ as the messaging infrastructure. RIB configures the native AQ server to behave as a JMS specification compliant JMS server. Therefore, it is strictly prohibited to manipulate RIB's JMS topics and RIB's AQ configurations directly with the AQ PL/SQL or Java API.
|
Note: For more information, see Chapter 6, JMS Provider Management, in the Oracle Retail Integration Bus Operations Guide. |
JMS Console is built on the following design principles:
Minimize impact to existing RIB systems
Work asynchronously wherever possible
Cache data to improve performance and reduce JMS resource usage
Collect data without increasing data size on the disk
Minimize configurations
Auto discover JMS server internals from existing metadata to avoid human error during configurations
Expose reusable Service APIs
Aware of customizing JMS topics
Simple to install and use
The architecture of JMS Console employs a modular design using separate layers for domain, service, and presentation. The service layers are implemented using stateless session beans using standard JavaEE 7 specifications. The presentation layer uses Oracle Application Development Framework (ADF).
Technical Specifications
JMS Console requires the following technical specifications:
Oracle WebLogic Server 12c.
Oracle Database which is compatible with RIB AQ version
Oracle Java 8 and JavaEE 7
The following diagram describes the console architecture.
The AQ JMS that the application is monitoring is configured as a JDBC data source in the application server. The application dynamically discovers the topics and subscribers configured in the AQ. The application interfaces with the AQ JMS using PL/SQL API's provided by the AQ and uses instrumentation techniques to collect statistics using PL/SQL procedures.
Monitoring data is stored in the same AQ schema that the application is configured to monitor and manage. The PL/SQL package JMS_MONITORING_AGENT is responsible for providing instrumentation hooks and data sourcing capabilities. Monitoring data is stored in the AQ_MESSAGE_METRIC table. The following the table structure definition of the AQ_MESSAGE_METRIC table:
| Column Name | Data Type | Nullable? | Description |
|---|---|---|---|
| TOPIC_NAME | VARCHAR2 (32 BYTE) | No | Name of the Topic |
| MONITORING_START_TIME | DATE | Yes | The time since JMS started to be monitored |
| TOTAL_MESSAGE_PROCESSED_COUNT | NUMBER | Yes | Total messages processed by this Topic |
| MOST_RECENT_ACTIVITY_TIME | DATE | Yes | Last en-queue/de-queue time on this Topic |
| DAILY_MSG_PROCESSED_COUNT | NUMBER | Yes | Total messages processed by this Topic since midnight |
| LAST_COUNT_RESET_TIME DATE | DATE | Yes | Time since the DAILY_MSG_PROCESSED_COUNT was last reset |
JMS Console uses the authentication mechanism configured in the application server. The application, by itself, does not authenticate the user nor stores user credentials. Authentication is delegated to the WebLogic server. Any authentication provider configured in the WebLogic server can be used for authenticating the users. Valid users belonging to JMSConsoleAdminGroup user group can access the system after successful authentication.
JMS Console allows you to access all integration messages. Some of these messages may contain financial or business critical information. For more information on which types of messages carry specific types of data, see the Integration Guide. Make sure to allow only trusted employees to access any data your organization classifies as sensitive.
Due to known vulnerabilities, Secure Sockets Layer (SSL) version 3.0 is not considered secure and should be disabled in WebLogic Server (WLS). For secured installations the latest Transport Layer Security (TLS) version is recommended.
JMS Console is available for all RIB AQ customers, independent of RIB version (customers with older versions of RIB can also utilize JMS Console). However JMS Console will not be back ported to 19.x.x RIB but customers should be able to use 19.x.x JMS Console in a 19.x.x AQ JMS environment.
|
Note: JMS Console is an add-on component and is delivered under RIB's product license. Standard product GA support is available from Oracle Support. |
Accessibility involves making your application usable for differently abled persons such as low vision or blindness, deafness, or other physical limitations. This means creating applications that can be used without a mouse (keyboard only), used with a screen reader for blind or low-vision users, and used without reliance on sound, color, or animation and timing.
JMS Console provides the ability to support the above accessibility in the applications.
Users should be able to navigate to all parts and functions of the application using the Tab and arrow keys, without using any keyboard shortcuts. In addition to that, keyboard shortcuts merely provide an additional way to access a function quickly.
Keyboard shortcuts provide an alternative to pointing devices for navigating the page. There are five types of keyboard shortcuts that can be provided in ADF Faces applications:
Tab traversal, using Tab and Shift+Tab keys: Moves the focus through UI elements on a screen.
Accelerator keys (hot keys): bypasses menu and page navigation, and performs an action directly, for example, Ctrl+C for Copy.
Access keys: Moves the focus to a specific UI element, for example, Alt+F for the File menu.
Default cursor/focus placement: Puts the initial focus on a component so that keyboard users can start interacting with the page without excessive navigation.
Enter key: Triggers an action when the cursor is in certain fields or when the focus is on a link or button.
