This chapter describes an example development of a Java jar file for the IBM Java Messaging Service calls and its deployment for use in an IBM Case Manager Workflow. See https://doi.org/10.13140/RG.2.2.21708.16001.
For the installation steps required for IBM Case Manager 5.3.3, which are covered step by step in the following free ResearchGate documents, downloaded using the DOI URLs as follows:
entitled “Case Manager 5.3.3 Installation on RHEL 8.0 with Content Navigator 3.0.6”
This gives the downloaded document, entitled CaseManagerInstallationonRHEL8.0_V3.docx.
The Audit system is based on an article in the journal, Quality Forum, Volume 19 No. 3, September 1993. The Journal of the Institute of Quality Assurance. Pages 116–126. The Quality Audit Process, by Alan S. Bluck (https://www.researchgate.net/publication/334095565_Case_Manager_Solution_Development#fullTextFileCssontent).
This chapter includes the steps for the development of a prototype system component, with code working with a Test harness including the development of a process for deploying and testing an AUDOperations.jar CI (Component Integration) jar file for use in a Workflow system step.
The IBM MQ Series is installed on a Linux VMware and requires the latest Fix Packs. After installation, we describe the setup test queues and the configuration of a JNDI link using a Tivoli Directory Services LDAP for LDAP context lookup.
An IBM MQ server is an installation supporting one or more queue managers that provide message queuing services to one or more clients. All the IBM MQ objects, for example, queues, exist only on the queue manager server. The MQ client does not store any MQ Objects. An IBM MQ MQI client is available which allows an application running on one system server to communicate with a queue manager running on another system server.
During development, it was found that the com.ibm.mq.jms.MQQueue cannot be cast to javax.jms.QueueConnectionFactory.
Chapter Organization
This chapter contains the following six Parts:
Part 1 – Bill of Materials. This Part lists the prerequisite IBM Software components, including the IBM product code numbers, required to download the latest IBM MQ Series software components, used to test the Java JMS message service API calls. It also covers the installation of the downloaded software on a Red Hat Linux server.
Part 2 – Custom Operations Component Development. The Custom Operations Component is defined in the subscribed Workflow as a special Component Integrator step, which we will describe in this Part.
Part 3 – Creating a Non-privileged MQ User for a Client Application Connection. This Part describes a procedure to create a non-privileged user ID to be used for a client application which connects to the queue manager. Access is granted for the client application only to be able to use the channel it needs and the queue it needs by use of this user ID.
Part 4 – Second Run of the AUDOperationsTest.java JUnit for JMS Messaging. This Part covers the second run of the JUnit test, which is more successful. The console screen output shown in Figure 3-232 is from the Eclipse IDE JUnit run of the AUDOperationsTest.java Class.
This shows the transmission of a test message to the IBM MQ Connection Factory, AUDCF3 queue, and the retrieval of the ten Audit Documents in the output list from the Audit Master Case Manager solution, Target Object Store.
Part 5 – Building the AUDOperations.jar. This Part describes the method for exporting the Java program in the AUDOperations.jar file with the exposed methods we wish to call from our IBM Process Designer Workflow.
Part 6 – Transferring Workflow and Setting Up Workflow Subscriptions. In this Part, the Target Object store, OS2, is updated with a Workflow Definition document class (AUD_JMSMessage.pep file), which is used to run the Workflow we created, triggered by a new Audit Report document created in the Target Object store from an Audit Master solution Case Manager Audit Department Case. The acce web Administration console is used to create the required Workflow Subscription.
Part 1 – Bill of Materials
The following URL link describes the latest available IBM MQ Series 9.x downloads and provides links to the versions of IBM MQ available for download:
www.ibm.com/docs/en/ibm-mq/9.2?topic=roadmap-mq-downloads
The next link displays the available pdf documentation for IBM MQ:
www.ibm.com/docs/en/ibm-mq/9.2?topic=am-mq-92-pdf-files-product-documentation-program-directories
The hardware and software requirements for IBM MQ series are described at this URL link:
www.ibm.com/support/pages/node/318077
An overview of the installation procedure for IBM MQ 9.2 can be seen at this link:
www.ibm.com/docs/en/ibm-mq/9.2?topic=uninstalling-installing-mq-linux
The development of a Java JMS message queue for Linux, Windows, and IBM Cloud is described in the following link:
https://developer.ibm.com/tutorials/mq-develop-mq-jms/
The version and product code details for the installations are as follows:
IBM SDK, Java (TM) Technology Edition, Version 8 for Linux (CND18ML)
IBM MQ V9.2.5 Continuous Delivery Release for Windows 64-bit Multilingual (M0458ML)
IBM MQ V9.2.x Continuous Delivery Quick Start Guide (G014JML)
- 1)First, we create the /home/IBM/MQ directory logged in as the root user:cd /homemkdir IBMcd IBMmkdir MQcd MQ
- 2)Copy the IBM_MQ_9.2.5_LINUX_X86-64.tar.gz file to the /home/IBM/MQ folder path created using wasadm on the ecmukdemo6 server:cp /mnt/hgfs/Installs/MQ/IBM_MQ_9.2.5_LINUX_X86-64.tar.gz .
- 3)The IBM MQ 9.2.5 installation is unpacked, and then we change to the MQServer subfolder:tar -zxvf IBM_MQ_9.2.5_LINUX_X86-64.tar.gzcd /home/IBM/MQM/MQServer
- 4)The license is registered using the following shell script:./mqlicense.sh -text_only
From IBM MQ 9.2.0, you have the option of accepting the license before or after installing the product. To accept the license before installing, run the mqlicense.sh script first.
Press Enter to continue viewing the license agreement, or enter “1” to accept the agreement, “2” to decline it, “3” to print it, “4” to read non-IBM terms, or “99” to go back to the previous screen.
1
- 5)The temporary environment variable used for installation is set as follows:mkdir /opt/IBM/software/mkdir /opt/IBM/software/tmpTMPDIR=/opt/IBM/software/tmp
- 6)
The rpm command is used to install the packages:
The preceding command causes the default directory path to be used.
The installation list of IBM MQ Series 9.2.5.0 components
The current root User limits need to be increased!
nofile (-Hn) 4096 files
and nofile (-Sn) 1024 files
These two limits need to be increased to 10240.
The root user limits can be changed as follows:
vi /root/.bashrc
ulimit -u unlimited
Also, the settings in /etc/security/limits.conf need to be edited.
Log in to the computer as the root user or as a user with sudo permissions.
Go to the /etc/security directory.
Open the limits.conf file for editing.
Save and close the file.
After changing the limits, the ecmukdemo6 system requires a reboot.
147 of 147 tasks have been completed successfully.
- 7)
env gives the following MQ-related environment variables.
The MQ-related environment variables
- 8)
Launch the MQ Explorer.
- 9)
The MQ Explorer GUI is shown in Figure 3-16.
The message displayed in Figure 3-16:
With this installation, existing local queue managers are displayed automatically in the Navigator view. However, the current user is not a member of the 'mqm' group and is therefore not authorized to use MQ control commands. The user will not be able to perform local queue manager operations such as create, start, stop and delete. To add a remote queue manager, right-click ‘Queue Managers’, and select ‘Add Remote Queue Manager’.
- 10)
So, we must add wasadm as a member of the mqm group:
This must be done for the mqm user; otherwise, the wasadm Q Manager create will fail with an error message.
- 11)
Log out and then log back in as wasadm for the changes to take effect.
- 12)
Now displays:
- 13)
Create a Queue Manager.
- 14)
Defaults are used for logging.
- 15)
Click Next> and select Permit a standby instance (tick box) and remote admin by Create server-connection channel (tick box) to allow remote.
From IBM MQ 9.2.0, you can configure your queue manager to automatically apply the contents of an MQSC script, or set of MQSC scripts, on every queue manager start. (This is also available from version 9.1.4 onward.)
(See www.ibm.com/docs/en/ibm-mq/9.2?topic=commands-automatic-configuration-from-mqsc-script-startup.)
The following link contains an example configuration:
- 17)
Use the default port 1414 and click Next>.
- 18)
Use a default 15-second refresh interval, click Apply Default, and click Finish.
- 19)
Queue Manager is now created.
- 20)
Click the wasadm node to show the status of the Queues created.
Notification of Successful Document Load into the FileNet Target Object Store OS2
JMS MQ Java Message from Content Object Store OS2, FileNet | |
---|---|
An event will be created in FileNet to send a real-time MQ message to the Quality Audit Database system, auditdb, when a new Audit Report Task Workflow is created. This message will pass back the following metadata. Timestamps will be generated as part of the messaging service: | |
Field ID | Attributes |
Case ID | |
Department Id | |
AuditDate | CCYY-MM-DD-HH.MM.SSSSSS |
Audit Report Id | |
Preconditions | An Audit Report document has been successfully loaded and stored in the FileNet Target (OS2) Object Store. |
Postconditions | A message containing the relevant information to identify the Department and the Audit Report Document will be placed on MQ, and an email alert will be issued from the Workflow operation system step to the Department manager. |
Exceptions | If MQ messages fail due to Audit Case processing issues or MQ being unavailable, the load of any new documents may be paused for a limited time period until the root cause of the issues is identified. Controls will be implemented where necessary to prevent a flood of MQ messages causing performance issues where a larger than normal volume of documents is processed (i.e., from a backlog following a Document load failure). |
- 1.
Add initial JMS Context.
None: The JNDI service provider does not require authentication. MQ Explorer connects to the initial context using anonymous authentication, and no security credentials are passed to the JNDI service provider.
Simple: The JNDI service provider requires simple authentication. MQ Explorer must pass the user-distinguished name and password to the JNDI service provider to connect to the initial context. (We select this option.)
CRAM MD5: The JNDI service provider requires CRAM-MD5 authentication. MQ Explorer must pass the MD5-encrypted password to the JNDI service provider to connect to the initial context.
Click the Finish command button.
Click OK on SYSTEM.DEFAULT.LOCAL.QUEUE.
The JMS Queue wizard is invoked.
Click OK.
The JMS MQ series queue is now set up ready to be processed.
The following link shows a simplified architecture diagram:
Part 2 – Custom Operations Component Development
A Workflow step can be used to call the sendJMSMessage Java method we develop, by using a Code Module .jar library imported as a CodeModule Document Class and then exposing this custom sendJMSMessage method by triggering the Workflow using a Workflow Subscription object, which can be linked to a Document Create Event object reference triggered on the creation of an Audit Report Document class.
The Custom Operations Component is defined in the subscribed Workflow as a special Component Integrator step, which we will describe in this Part.
There are a number of links to code examples which are the basis for the IBM Content Engine and Process Engine Workflow component steps, which can be found on GitHub:
https://github.com/ibm-ecm/ibm-content-platform-engine-samples
The following IBM License is displayed in the code samples I have used in this book:
The following DemoJava.zip download link contains the code for the core connection Java for links to the IBM MQ Series JMS Queues:
See also Chapter 2, in the start of the section “Configuring Java Components for Content Engine Events,” to see the step-by step screenshots and procedure for creating a new Eclipse Java Project.
This Component Integrator code component is described in overview in the IBM Documentation:
www.ibm.com/docs/en/filenet-p8-platform/5.5.x?topic=tools-component-integrator
and in more detail with the following link:
“Developing Component Integrator-Based Work Performers – IBM Documentation”
The following IBM Technote has a link to a downloadable pdf document, which describes changes in the deployment for the Component Integrator Java libraries, into the Component Manager, which were introduced in the IBM FileNet P8 5.2 Component Manager version.
See www-01.ibm.com/support/docview.wss?uid=swg27043131.
From this downloaded pdf document, Migrating to the 5.2 Component Manager.pdf, it should be noted that the JAR files are added to the object store as a code module, as we described for the Event Handler Java library in Chapter 2. It is also recommended that either the JAR file is stored as a separate content element (since the code module is a versionable object, and JAR files can be added, removed, and updated as required), where the same code module Object can be used by more than one component queue, or, as IBM recommends, that the best practice is to use a separate code module for each component queue.
Creating the AUD_CIOps Java Project
The new Java Project is created as AUD_CIOps.
The specification for the AUDOperations Component Integrator code module
The code for the CELoginModule Class, working at FileNet P8 5.5.x, is listed at the following link:
www.ibm.com/docs/fr/filenet-p8-platform/5.5.x?topic=performers-celoginmodule-class
A Jar file is created to test the base compilation and functionality.
The AUDOperations.java code for the Component Integrator
Adding the Supporting Library JAR Files
- a)
First, we add the same IBM FileNet P8 API library .jar files to the Classpath as we added in Chapter 2. Additionally, we need to add the JMS Message library, javax.jms-api-2.0.1.jar, to the Eclipse IDE classpath.
Create the MQJars folder for the jar files we need:(base) [root@ECMUKDEMO6 opt]# mkdir MQJars(base) [root@ECMUKDEMO6 opt]# cd MQJars(base) [root@ECMUKDEMO6 MQJars]# pwd/opt/MQJars - b)From the MQJars folder, download the com.ibm.mq.allclient.jar file by using curl:(base) [root@ECMUKDEMO6 MQJars]#curl -o com.ibm.mq.allclient-9.2.4.0.jar https://repo1.maven.org/maven2/com/ibm/mq/com.ibm.mq.allclient/9.2.4.0/com.ibm.mq.allclient-9.2.4.0.jar
- c)From the MQJars folder, download the JMS API file by using curl:curl -o javax.jms-api-2.0.1.jar https://repo1.maven.org/maven2/javax/jms/javax.jms-api/2.0.1/javax.jms-api-2.0.1.jar
- d)From the MQJars folder, download the JSON .jar file by using curl:curl -o json-20211205.jar https://repo1.maven.org/maven2/org/json/json/20211205/json-20211205.jar
- e)
Set the security on the /opt/MQJars and the contained .jar files:
- f)
In the Eclipse project Classpath, we now add the preceding downloaded .jar files.
Installing the IBM JRE Java SDK 1.8
We also need to install and load the IBM JRE jre1.8.0.261 Java JRE library on Red Hat Linux 8.0, using the download URL:
For Eclipse on Windows systems, the following URL link can be used.
Click Next on the Installation summary page (or you can cancel at this point).
Next, we need to create a configuration.properties file to hold the required JMS Queue details.
Creating the configuration.properties File
The configuration.properties JUnit test file
Initially, this configuration.properties file was added to the project src folder, but we reference this from a package folder, so it was moved (dragged and dropped) to the com.ibm.filenet.ps.ciops.test subfolder under the src folder.
Creating the Test Java Package and Code
The AUDOperationsTest.java code used for JUnit testing
The comment //$NON-NLS-1$ at the end of some statements is the way to communicate to the compiler that UI messages should not be embedded as string literals, but rather sourced from a resource file (so that they can be translated or easily modified, etc.). Consequently, Eclipse can be configured to detect string literals, so that you don’t accidentally leave unexternalized UI strings in the code. Also, note that some strings, such as regular expressions, are not externalized.
The Configuration.java code file used to load the Configuration.properties
Initial Error Fixes
- 1)First run of the JUnit test class, AUDOperationsTest, we getJVMCFRE003 bad major version; class=com/ibm/filenet/ps/ciops/test/AUDOperationsTest, offset=6
indicating that the compiled class JRE is different from the JVM version, so this was changed in the Eclipse project from 1.7 to 1.8.
The initial document we selected had a Title with spaces in the path, which gave the preceding E_OBJECT_NOT_FOUND FileNet error.
(/AUDIT_TEST/Audit Event Test Version 2 was used initially.)
We found that the code to retrieve a document requires a Document path which does not have the document title with spaces.
The updated Configuration.properties file
So, now we get the error indicating that the class com.ibm.mq.jms.MQQueue cannot be cast to javax.jms.ConnectionFactory.
There is an IBM Technote for this; see the link:
In summary, the ClassCastException occurs when a queue connection factory is defined as a WebSphere MQ Connection Factory instead of a WebSphere MQ Queue Connection Factory.
Define the queue connection factory as a WebSphere MQ Queue Connection Factory.
Use a javax.jms.ConnectionFactory object in the application code rather than a javax.jms.QueueConnectionFactory object.
Configuring the Ports and Library Jar Files for IBM MQ Series
The server Firewall is now updated to allow the MQ Series port 1414 to be opened.
Added providerutil.jar from the path:
MQ Series Channel Security Settings
The security is set to provide limited access to the stored messages held in the MQ Series message queues.
Read additional information in
“Configuring and running simple JMS P2P and Pub/Sub applications in MQ 7.0, 7.1, 7.5 and 8.0”
www-01.ibm.com/support/docview.wss?uid=swg27023212&aid=1
(IBM Techdoc: 7023212)
See the IBM Technote:
www-01.ibm.com/support/docview.wss?uid=swg21138961
and
www-01.ibm.com/support/docview.wss?uid=swg21577137
The default value for the new feature introduced in 7.1, “Channel Authentication Records” (CHLAUTH), is ENABLED.
The last record blocks all remote channel access to any MQ Administrator. The effect is that non-administrative users can still connect if suitably authorized to do so, but administrative connections and anonymous connections are disallowed regardless of any Object Authority Manager (OAM) authorization settings. This means that new queue managers in V7.1 are much more secure by default than in previous versions, but with the trade-off that administrative access must be explicitly defined.
1) If this is a production queue manager, then you could stop trying to use a userid that is an MQ Administrator and instead use a non-administrator userid to access the queue manager.
2) If you really want the MQ Administrator to be able to access the queue manager via client channels, you could do one of the following actions:
2a) You can add the following two Channel Authentication Records.
User ID blocking
The preceding rules apply to SYSTEM.ADMIN.SVRCONN which is used by the MQ Explorer.
It is not advisable to use SYSTEM.DEF.* channels for active connections. The system default channels are the objects from which all user-defined channels inherit properties. The recommended practice is that SYSTEM.DEF.* and SYSTEM.AUTO.* channels should NOT be configured to be usable.
2b) This is a variation of (2a) but allowing the MQ Administrator to only use a particular host.
Note Disabling CHLAUTH results in a policy that accepts administrative connections by default. The administrative effort to lock down administrative access with CHLAUTH(DISABLED) is much greater than to do so with CHLAUTH(ENABLED).
It is recommended to leave CHLAUTH(ENABLED) and use the other security features of MQ V9.2.x to authenticate administrator connections.
Create a CRL LDAP Authentication
See www.ibm.com/docs/en/ibm-mq/9.2?topic=manager-accessing-crls-arls-using-mq-explorer.
Certificate Revocation Lists (CRLs) also apply to Authority Revocation Lists (ARLs).
For the overview of the use of the CRL lists used for security, see
www.ibm.com/docs/en/ibm-mq/9.2?topic=users-working-revoked-certificates
- 1.
Ensure that you have started your queue manager.
- 2.
Right-click the Authentication Information folder and click New ➤ Authentication Information. In the property sheet that opens:
- a.
On the first page, Create Authentication Information, enter a name for the CRL (LDAP) object.
- b.
Enter the LDAP server name (ecmukdemo6) as either the network name or the IP address.
- c.
If the server requires login details, provide a user ID and, if necessary, a password. (This system used cn=root and filenet.)
- 3.
Right-click the Namelists folder and click New ➤ Namelist. In the property sheet that opens:
- a.
Type a name for the Namelist (AUDNAMES).
- b.
Add the name of the CRL (LDAP) object (mquser1, from step 2a) to the list.
- c.
Click OK.
- 4.
Right-click the queue manager, select Properties, and select the SSL page.
- a.
Select the Check certificates received by this queue manager against Certification Revocation Lists check box.
- b.
Type the name of the namelist (AUDNAMES from step 3a) in the CRL Namelist field.
Next, we need to create a New Client connection Channel, AUD.CLNTCONN.
Part 3 – Creating a Non-privileged MQ User for a Client Application Connection
The instructions from this link were followed:
www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.dev.doc/q023960_.htm?lang=en
This procedure creates a non-privileged user ID to be used for a client application which connects to the queue manager. Access is granted for the client application only to be able to use the channel it needs and the queue it needs by use of this user ID.
Procedure
- 1.
Obtain a user ID on the system where the queue manager is running on (the server ecmukdemo6 in this example).
- 2.
For this task, this user ID must not be a privileged administrative user. This user ID will be the authority under which the client connection will run on the queue manager.
- 3.
Start a listener program with the following commands where
qmgr-name is the name of your queue manager.
nnnn is your chosen port number.
For UNIX and Windows systems:
channel-name is the name of your channel.
- 4.Create a channel authentication rule allowing only the IP address of your client system to use the channel by issuing the MQSC command:SET CHLAUTH(' channel-name ') TYPE(ADDRESSMAP) ADDRESS(' client-machine-IP-address ') +MCAUSER(' non-privileged-user-id ')In the command window:su - mqmrunmqsc wasadmSET CHLAUTH('SYSTEM.ADMIN.SVRCONN') TYPE(ADDRESSMAP) ADDRESS('10.10.10.90') MCAUSER('db2inst1')
channel-name is the name of your channel.
client-machine-IP-address is the IP address of your client system.
If your sample client application is running on the same machine as the queue manager, then use an IP address of “127.0.0.1” if your application is going to connect using “localhost.” If several different client machines are going to connect in, you can use a pattern or a range instead of a single IP address. See www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.ref.adm.doc/q086080_.htm?lang=en-us (Generic IP addresses) for details.
non-privileged-user-id is the user ID you obtained in step 1.
- 5.
If your application uses the SYSTEM.DEFAULT.LOCAL.QUEUE, then this queue is already defined. If your application uses another queue, create it by issuing the MQSC command:
queue-name is the name of your queue.
- 6.
Grant access to connect to and inquire the queue manager:
For IBM i, UNIX, and Windows systems, issue the MQSC commands:
non-privileged-user-id is the user ID you obtained in step 1.
For IBM i, UNIX, and Windows systems, issue the MQSC commands:
SET AUTHREC PROFILE(‘ queue-name ‘) OBJTYPE(QUEUE) +
PRINCIPAL(‘ non-privileged-user-id ‘) AUTHADD(PUT, GET, INQ, BROWSE)
queue-name is the name of your queue.
non-privileged-user-id is the user ID you obtained in step 1.
- 7.If your application is a publish/subscribe application, that is, it makes use of topics, grant access to allow publishing and subscribing using your topic by the user ID to be used, by issuing the MQSC commands:
For IBM i, UNIX, and Windows systems, issue the MQSC commands:
non-privileged-user-id is the user ID you obtained in step 1.
This will give non-privileged-user-id access to any topic in the topic tree; alternatively, you can define a topic object using DEFINE TOPIC and grant accesses only to the part of the topic tree referenced by that topic object. See www-01.ibm.com/support/knowledgecenter/SSFKSJ_8.0.0/com.ibm.mq.sec.doc/q013980_.htm?lang=en-us (Controlling user access to topics) for details.
A command-line preview is shown in the New Authorities screen.
In the Navigator view, right-click the queue manager, then click Manage Authority Records. The Manage Authority Records dialog opens.
Highlight the record for the user or group to which you want to add the Connect authority, then click Edit…. The Edit Authorities dialog opens.
Select the Connect check box, then click OK.
The user now has Connect access to the queue manager. When the user accesses the queue manager’s objects, the authorities that you have granted to the user take effect.
Listener Authorities
Create test for example MQ Main program REF:
Stopping and Starting the Queue Manager
- 1.
End all the activity of queue managers associated with the WebSphere MQ installation.
- a.
Run the dspmq command to list the state of all the queue managers on the system.
- b.
Run the MQSC command, DISPLAY LSSTATUS(*) STATUS, to list the status of listeners associated with a queue manager:
- c.
Stop any listeners associated with the queue managers, using the command:
- a)
Restart the MQ wasadm Queue.
Creating a Client Channel for Messaging
A custom Client Channel can be created for messaging based on a standard SYSTEM.DEF.SERVER template Object type, as shown in this section.
Setting Up the Client on Linux
Set up the client component using the MQSERVER environment variable.
We need to find out the network name of the machine which hosts the queue manager (our example QM is called wasadm) from the system administrator.
Log in as the user who will be running the Express File Transfer, who must be a member of the mqm group. (On the ecmukdemo6 Linux server, this is wasadm.)
Open a command prompt.
Replace hostname with the name (ecmukdemo6) that identifies the server machine on the network.
Close the command prompt.
Log out and log back in for the change to take effect.
You have now set up the client and server components needed. The next task is to send a message from the client to the server queue manager wasadm.
Sending a Message from a Client to a Server
To send a message from the client to the server queue manager wasadm, which uses the remote queue definition AUDQAR:
Open a command prompt on the client and follow these steps:
Start the amqsputc sample program as follows.
Testing for Errors
The error "Dead-letter Queue attribute refers to a queue that does not exist (AUDD1) wasadm Queue Manager / General"
Remediation for Missing Dead-Letter Queue, AUDD1
Remediation for Missing Local Queue, AUDQ1
Now we need to change the AUDQ1 to Transmission usage.
Error Log Location
This was returned from the existing project.
Part 4 – Second Run of the AUDOperationsTest.java JUnit for JMS Messaging
The second run of the JUnit test is more successful. The console screen output in Figure 3-232 is from the Eclipse IDE JUnit run of the AUDOperationsTest.java Class.
Code Now Updated As Follows for AUDOperations.java
The AUDOperations.java code is updated for rebuild and deployment
AUDOperations Rebuild and Deploy .jar: Final Prebuild Test
The JUnit test output after adding the log4j.xml and log4j.dtd files
Part 5 – Building the AUDOperations.jar
The AUDOperations.jardesc file list
Rebuilding the AUDOperations.jar File
To rebuild the AUDOperations.jar file, we can make use of the AUDOperations.jardesc file we created.
Make a backup (if required) of the previous AUDOperations.jar first!
Right-click this AUDOperations.jardesc file in the Project area AUD_CIOPS and select Create Jar from the menu, then click Yes when prompted to overwrite the existing AUDOperations.jar file. (Click OK.)
Copy the compressed AUDOperations.jar file to the Installs folder for import as a System Component Integrator step.
The latest configuration.properties JUnit test file parameters
FileNet Workflow System Component AUDOperations.jar Deployment
- a)
Log in to the FileNet Administration Console for Content Engine (acce) web application configuration tool.
- b)
First, import the AUDOperations.jar file as a new Code Module.
- c)
Select the required Object Store Workflow System node as shown in Figure 3-258.
- a)
In the object store navigation pane, click the Administrative ➤ Workflow System ➤ Isolated Regions folder and click the isolated region that you want to modify.
- b)
Right-click the Component Queues folder and click New Component Queue.
- c)
The AUDOperations.jar Code Module we created earlier is loaded.
- d)
Then, the AUDOperations.jar file Code Module we added earlier is selected.
- e)
Select the previously loaded AUD_Operations code module.
The preceding steps were repeated for the OS1 Design Object Store.
The sendJMSMessage method sends a message to the AUDQAR MQ System.
Editing the Parameters
Next, the 15 parameters are edited with their names on the Parameters tab.
Because of the way in which these parameters are sorted, you might find it easier to keep track of the order by deleting all the template parameters and then adding them back one at a time since it is easy for the parameter order to be set mismatching the Java method argument call order.
Checking the Deployment in Component Manager and Workflow
This loads a pop-up window prompting us for a Process Engine administrator login (see Chapter 2, Figure 2-190).
IBM Process Designer Component Queue Configuration
It was discovered that the following original section of code (lines in red bold) caused Java reflection to fail in the import tool, so parameters were not exposed!
Part 6 – Transferring Workflow and Setting Up Workflow Subscriptions
Creating a Workflow Subscription on a New Audit Report Document Event
The Target Object store, OS2, with a Workflow Definition document class (AUD_JMSMessage.pep file) is used to run the Workflow we created, after a new Audit Report document is created in the Target Object store from an Audit Master solution Case Manager Audit Department Case.
Transferring the JMS Test Workflow to the Target Object Store
Testing the Updated Audit Master Solution
Chapter 3 Exercises
The following questions relate to the sendJMSMessage Java Component Integrator method developed for use with the IBM Process Designer Workflow subscriptions and the Case Manager, Audit Master Solution, which we cover in this chapter.
- 1.What script would you run to accept the IBM MQ 9.2.x license before installation?
- a)
pedesigner.bat
- b)
cmd.exe
- c)
mqlicense.sh
- d)
amqsputc
- 2.
What is the solution if you get the following JMS Java message:
- a)
A queue connection factory must be defined as a WebSphere MQ Connection Factory.
- b)
A queue connection factory must be defined as a WebSphere MQ Queue Connection Factory.
- c)
Use a javax.jms.QueueConnectionFactory object.
- d)
Use the Java code: TextMessage outMessage = JMSsession.createTextMessage();
- 3.
What change do you need to make if you get the Java runtime error in Eclipse as follows:
- a)
Add the JMS Message library, javax.jms-api-2.0.1.jar, to the Eclipse IDE classpath.
- b)
Add two new lines to the /etc/security/limits.conf file; @root soft nofile 10240 and @root hard nofile 16384.
- c)
Change the JVM version in the Eclipse project from 1.7 to 1.8.
- d)
Add jars from the /opt/MQJars folder to the Eclipse Classpath.
- 4.
The main purpose of a Workflow Subscription is
- a)
To enable the creation of a Folder Object
- b)
To enable the creation of a Document Object
- c)
To enable a workflow to be launched on the storage of a document
- d)
To enable a Case to be created in IBM Case Manager
- 1.
c) mqlicense.sh
- 2.
b) A queue connection factory must be defined as a WebSphere MQ Queue Connection Factory.
- 3.
c) Change the JVM version in the Eclipse project from 1.7 to 1.8.
- 4.
c) To enable a workflow to be launched on the storage of a document
- 1.
Describe what steps you would use to install a new Component Integrator, given that you have been given a working AUDOperations.jar file and have been asked to configure a sendJMSMessage custom operations method call step in a Workflow.
- 2.
What security group(s) do you need to have to run the IBM MQ Explorer program and what commands would you need to run to use this from a Unix command window?
- 3.
What Java libraries would you install in an Eclipse IDE Classpath to develop a Component Integrator Java class and where would you find them?
In Chapter 4, we will cover the use of the Java language for the IBM FileNet Java API calls and the configuration required to replicate an IBM FileNet Document Management Object Store.