How to Delete Process Applications from IBM BPM

As a new feature of the Business Process Manager V7.5.1 platform, process applications can now be deleted from the repository.  In the previous version of BPM, version 7.5.0 & 7.5.0.1, users could only archive snapshots within a process application.  This did not remove the application; rather it was merely hidden from the default view and it was still stored in the repository and the database.

In the latest version of BPM, users can now actually delete the process application, and in turn, delete all snapshots and instances tied to that application, including deletion of these entries from the database.

To delete a process application, click on the process application that you want to delete and then click on Manage.

 

Next, click on Archive Process App and click on Archive.

 

 

Click on the Process Apps tab of Process Center and then click on Archived.

 

 

Click on the process app that you previously archived and select Delete Process App, click on Delete.

 

 

If you then return to the Process Apps tab in Process center, you will notice that the process app no longer appears in the list.

We can actually confirm that all database entries are also removed as part of the process app deletion. Here we can see that the entry for our application named TestApplication was added to the BPMDB in the table LSW_PROJECT.

 

 

After deleting the process app, this entry is no longer present in the table.  If the application contained snapshots and BPDs, these entries would also be removed from the LSW_SNAPSHOT and LSW_BPD tables respectively.

Please keep in mind, that this cleanup only happens in Process Center. Currently, the product does not have the capaibility to clean up these components on the Process Server side. However, this is an important new feature to help keep your Process Center repository clean and its database clean and efficient.

View mqsisetdbparms settings in IBM Integration Bus

Example:

mqsisetdbparms IB9NODE -n ldap::myldap.com -u ldap01 -p ibm

mqsisetdbparms IB9NODE -n jdbc::mySecurityIdentity -u muthu -p ibm

mqsisetdbparms  Settings Location:
==========================
Windows XP:  C:\Documents and Settings\All Users\Application Data\IBM\MQSI\registry\IB9NODE\CurrentVersion\DSN

Windows 7  : C:\ProgramData\IBM\MQSI\registry\IB9NODE \CurrentVersion\DSN









Unix : /var/mqsi/registry/IB9NODE/DSN/

Issue: Packages IBM Websphere Process Server 7.0.0.0 and IBM Webpshere Integration Developer 7.0.0.0 cannot coexist in the same package group

Problem:

Package Group name contain only IBM WEBSPHERE INTEGRATION SERVER BUT NOT APPLICATION SERVER. (we need both in the package group name)

Solution:

1. Open the shortcut "IBM Installtion Manager"
2. Click "Install" Icon, select next -> click Repository link
3. It will take you to the repository page.
4. Add the repository.config file from ..\WID7.0\WTE_Disk\repository.
5. Add another repository.config file from C:\program files\ibm\Installation Manager\eclipse
6. Click Test connection for successfull connection.
7. Exit and Click import Icon.
8. Select the default directory location to C:\program files\ibm\WID7_WTE\runtimes\bi_v7.
9. Click next and import it.
10. Now, you can able to install Websphere Test Environment without any issue.

Restarting Application Servers With Nodeagent – WebSphere Application Server V7,V8

In WebSphere 7 or 8, by default, the Nodeagent will take no action if an application server fails.  To have the Nodeagent intervene and automatically restart a failed application server instance, the ‘monitoring policy’ must be set for that application server.  In the admin console, perform the following:

1 . –> Java and Process Management –> Monitoring Policy
2.  Check the box next to “Automatic Restart”
3.  In the “Node Restart State“, set the state to “STOPPED”


The actions above will allow the nodeagent to auto-restart a failed or killed application server.  It is important that the ‘Node Restart State” be set to ‘STOPPED“.  If set to “RUNNING“, not only will the nodeagent restart a failed or killed application server, but it will autostart the application server upon a nodeagent restart.  This may be unwanted in certain environments where application servers are only supposed to run at certain times or if there is a specific application start order.
If you wish to have the nodeagent automatically start application servers when it comes online, set the state to “RUNNING“.

Stuck messages occur for WebSphere Process Server (WPS) and WebSphere Enterprise Service Bus (WESB) on SCA.SYSTEM.etail_cell01.Bus destinations.

Environment

The problem can occur in WebSphere Process Server or WebSphere Enterprise Service Bus-related modules that are deployed on a server or clustered environment. This problem occurs only for asynchronous messaging on SCA modules.

Diagnosing the problem

To diagnose the problem, monitor the queue destinations for the message counter and review the settings for the forward routing path of the affected queue destinations.

Monitor the queue destinations in an asynchronous communication scenario. If the number of messages on the queue only increases, then the messages are not routed forward. This scenario applies to destinations that do not have a defined forward routing path (except the module destination, which has an applied MDB, which reads the messages from the queue).

Use the Service Integration Bus Explorer to monitor module-related queues or review the number of messages on the queue using the administrative console:

Administrative console Service integration Buses SCA.SYSTEM.cellName.Bus Destinations sca/destinationName Queue points destinationName@messagingEngineName Runtime tab Current message depth

Use the refresh button to get the current value of the message counter to monitor the behavior over time:





Stuck messages on the module destination queue (optional)
If messages remain on the module destination queue, verify that the activation specification of the MDB that is listening on that queue is configured correctly:

Administrative console Resources Resource adapters J2C activation specifications sca/moduleName/ActivationSpec J2C activation specification custom properties

Check that busName refers to the correct SCA bus (SCA.SYSTEM.cellName.Bus) and that destinationName refers to the module destination (sca/moduleName).

Resolving the problem

Follow this procedure to resolve the problem:

1. Identify the destination where messages are stuck.
2. Set the correct forward routing path on the destination (set the path to the module destination).
3. Save the master configuration. 

Example :

Destination Name : sca/PubProdMED/component/PubProdMF
ModuleName :  PubProdMED
Routing Path:


The messages should immediately be routed to the specified target destination. You do not need to restart the server.

Deleting Records From Failed Event Manager In Websphere Application Server [ WESB & WPS ]

The WebSphere application server stores all exception's in failed event manager. If FEM is full, then clearing FEM Records through Admin Console is not possible.

In this situation, we have two options to remove all FEM.

Option 1:
=======

Delete FEM records from WPSDB database . Run the below query in order.

delete from FAILEDEVENTS;
delete from FAILEDEVENTBOTYPES;
delete from FAILEDEVENTDETAIL;


Option 2:
=======

Delete FEM by jython scripts.

The script must be saved in a file and can be run on a single server profile as well as a
clustered environment (run on deployment manager) using the following command:

1.  cd Deployment manager  [ or ] Profile Name/bin 
2.   Run wsadmin.(bat|sh) -lang jython -f jythonScriptName -user wpsAdminUserName -password wpsAdminPassword

Ex: wsadmin.bat -lang jython -f /opt/Websphere/AppServer/scripts/FEMScript.py -user admin -password admin


FEMScript.py
===========
# lookup the failed event manager
objstr = AdminControl.completeObjectName('WebSphere:*,type=FailedEventManager')
obj = AdminControl.makeObjectName(objstr)

# count the overall number of failed events
fecount = AdminControl.invoke(objstr,"getFailedEventCount")
print "Failed event number before discarding: ", fecount

delnum = 100
fecount = int(fecount)

while (fecount > 0):
    if fecount < 100:
        delnum = fecount
        fecount = 0
    else:
        delnum = 100
        fecount = fecount - 100
      
    # get 100 failed events
    msglist = AdminControl.invoke_jmx(obj,'getAllFailedEvents',[delnum],['int'])

    # discard 100 events in single batch run
    print "Discarding ", delnum, " failed events"
    AdminControl.invoke_jmx(obj,'discardFailedEvents', [msglist],['java.util.List'])

# count the overall number of failed events
fecount2 = AdminControl.invoke(objstr,"getFailedEventCount")
print "Failed event number after discarding: ", fecount2

WPS : Unable to Install appllication on server "Application is already Exist on Server". Module status is unknown in SCA module section.

Issue: I am trying to install one application on server. It's unable to install giving exception as " already exist on server".
In admin console go to --> SCAModules : there i am finding my module over there but the state of the module is unknown. i tryed to un-deploy from there. it's not able to un-deploy. Even i am unable to remove that application from server from admin consol too..

Solution :
1. first we have to stop the server.
2. we have to remove particular application from all the folder in server profile.
3.One more main thing is go to installation folder-->  \profiles\qbpmaps\config\cells\qcell go to this path and open "cell-core.xml" file and remove SCAModules entry of that particular application from this file.
4. Start the server
now we can able to deploy that same application successfully.


OR

You can also force the uninstall with the following command:

<>\bin\wsadmin.bat -user <> -password <> -lang jacl -f <>\ProcessChoreographer\admin\bpcTemplates.jacl -uninstall <> -force

WAS 7 – Busines level Application can not be removed

In WAS 7, IBM introduced the new concept BLA (business level application) which can include EAR, JAR or share libraries.

However, some times when you update a EAR file from console but failed, which cause the Enterprise Application was removed but BLA was still left. When you redeploy the same module, the module can not be deployed, and you will see the following error when you want to delete the existing BLA:
CWWMH0149E: Cannot delete business-level application “WebSphere:blaname=AppEAR” because it contains composition units. Delete all composition units which belong to the business-level application, and then delete the business-level application. Check log for details.
As a matter of fact, you already removed all composition units, and you can not see any composition units belong to this BLA from administrative console or even using wsadmin scripts.

Here is a way for how to remove the isolated BLA if BLA can not be removed without any composition units belonging to it.

1) stop the WebSphere Application Server.
2) backup the WebSphere profile configuration using “backupConfig.sh” command
3) go to directory /config/cells//blas
4) remove the directory of specified BLA
5) go to directory /config/cells//cus
6) remove the directory of specified BLA
7) go to directory config, remove temp directory
8) go to directory , remove wstemp and temp directory
9) restart the WebSphere Application Server
10) redeploy the module.
this is the way I solved this problem. I hope someone can provide the better way to solve this issue.

Using WebSphere variable in JavaEE application

There is a section in the WebSphere Admin console called WebSphere variables (located under Environment), where you can … manage WebSphere variables (WAS variables). But how can one use these WAS variables within a JavaEE application? There is a proprietary way to load them which I will not mention here.

A better way in my opinion is to bridge the WAS variable to an environment variable. Then it can simply be accessed through System.getProperty(“varName”); It’s also easy to access the variable on Tomcat without touching the code.

To bridge a WAS variable:

1. Log on to your WAS console.
2. Add a WAS variable “myapp.myVar” under Environment -> WebSphere variables
3. Go to (something llike) Servers -> Server Types -> Websphere application servers -> YOUR_SERVER -> Java and process management -> Process definition -> Java virtual machine -> Custmo properties
4. Define a new variable myapp.myVar = ${myapp.myVar}
5. Save and restart.

The value of myapp.myVar can now be obtained: System.getProperty(“myapp.myVar”)

Note : 

If you have cluster environment then this configuration should be in all server of cluster.