Pythagoras Cup - Greedy Cup

Was just surfing the youtube yesterday and found below. Really interesting.

Hope you like it.

UCA disappearing from Event Monitor or Corrupted UCA problem in IBM BPM - Solved

Problem Description - 

==============

Facing issues with Event Monitor related to UCA scheduling , its behaving weird the entries are randomly disappearing from the scheduler .

Even after re-enabling(checking unchecking from the application side) , the UCA appear in event Monitor for short time and disappear after one run or after some time.

Reason for Problem -

=============

When a time-based UCA is scheduled, an event manager task in the

LSW_EM_TASK table and two keywords in the LSW_EM_TASK_KEYWORDS 

table are created. These keywords are 'UCA4.<uca-id>' and 

'scheduledExec'. On rare occasions, you might see event manager 

tasks for time-based UCAs that have only the 'scheduledExec' 

keyword. When a UCA is rescheduled, the keywords are used to 

delete the previous event manager task.  However, having only 

the 'scheduledExec' keyword for a particular UCA could cause all 

other time-based UCAs to be deleted during the rescheduling 

process.

In our case we believed reason for this problem was due to our DB file system was running at 100% at couple of times.

Solution -

======

The proposed solution is to manually delete the corrupted task from the database. This must be done carefully in order to not corrupt the whole database. The following queries should be executed at times     

where they do not interfere with the scheduling time of the UCA, i.e. not at full hours, or 5,15,25,35,45 or 55 minutes after full hours or you UCA is about to get executed.

There are can be two type of problem as one of the keyword for perticular UCA is not present. I will explain both scenarios.

Scenario 1 -

------------

1.) Retrieve TASK_IDs for scheduled UCAs that have only the 'scheduledExec' keyword, but not the uca id keyword:

select task_id from lsw_em_task_keywords where keyword = 'scheduledExec' and task_id not in ( select task_id  from lsw_em_task_keywords where keyword like 'uca4%')

2.) Display description and ID of ucas returned by query2:  

select description,task_arguments_str from lsw_em_task where task_id in(select task_id from lsw_em_task_keywords where keyword = 'scheduledExec' and task_id not in ( select task_id  from lsw_em_task_keywords where keyword like 'uca4%'))

3.) If the result of query 2 shows only tasks with description "Execute UCA <UCA_Name> <Schedule>, on set schedule", then you can delete the corrupt UCA and keyword with the following queries:  

3.1) Delete corrupted lsw_em_task: 

delete from lsw_em_task where task_id in (select task_id from lsw_em_task_keywords where keyword = 'scheduledExec' and task_id not in (select task_id  from lsw_em_task_keywords where keyword like 'uca4%'))

3.2) Delete corrupted lsw_em_task_keyword:

delete from lsw_em_task_keywords where task_id in (select task_id from lsw_em_task_keywords where keyword = 'scheduledExec' and task_id not in (select task_id  from lsw_em_task_keywords where keyword like 'uca4%'))

Scenario 2 -

------------

1.) Retrieve TASK_IDs for scheduled UCAs that have only the  uca id keyword, but not the 'scheduledExec' keyword:

select task_id from lsw_em_task_keywords where keyword = 'uca4%' and task_id not in ( select task_id  from lsw_em_task_keywords where keyword like 'scheduledExec')

2.) Display description and ID of ucas returned by query2:

select description,task_arguments_str from lsw_em_task where task_id in (select task_id from lsw_em_task_keywords where keyword = 'uca4%' and task_id not in ( select task_id  from lsw_em_task_keywords where keyword like 'scheduledExec'))

3.) If the result of query 2 shows only tasks with description " Execute UCA <UCA Name>, on set schedule",then you can delete the corrupt UCA and keyword with the following queries:  

3.1)  Delete corrupted lsw_em_task:

delete from lsw_em_task where task_id in (select task_id from lsw_em_task_keywords where keyword = 'uca4%' and task_id not in (select task_id  from lsw_em_task_keywords where keyword like 'scheduledExec'))                                                       

                                                                        

3.2) Delete corrupted lsw_em_task_keyword:

delete from lsw_em_task_keywords where task_id in (select task_id from lsw_em_task_keywords where keyword = 'uca4%' and task_id not in (select task_id  from lsw_em_task_keywords where keyword like 'scheduledExec'))       

You could also only delete the corrupt task keyword with Query4. APAR JR47574 will then take care, that the associated UCA task is not executed and not rescheduled

Changing Configuration in IBM BPM Configuration file usitn 100Custom.xml

In IBM BPM most of the configuration details are stored in 99Custom.xml file. There are lots of instances when you need to change this default settings/configuration to the customized one.

When ever you modify a server configuration,always make the changes to the 100Custom.xml file,not to the original configuration file.In this way , all customization's are captured in a single file and are readily available if you upgrade to a new version of IBM BPM. This is the recomanded process as it is very easy to rollback from here without forgetting what was the “out-of-box/Defualt“ value for the given parameter/tag.

For example, the 100Custom.xml and 99Local .xml files are stored in the profile root for the server, where the value is either process-center or process-server, depending on which server you are configuring.  

The configuration files in the ../config/ directories are loaded in numerical order. For example, the standard files are loaded in this order: 00Static.xml, 50AppServer.xml, 60Database.xml, 80EventManager.xml, 98Database.xml, 99Local.xml, 100Custom.xml. By default, the first time the element that is loaded, it will stick in the configuration. For example,  then the one in 99Local.xmlfile loads first, unless the merge attribute is set to replace.

According to explanation on above paragraph, you can create any file of your choice having customized tag which replaces the default configuration.

Using the 100Custom.xml file to add new configuration values or replace existing values
The 100Custom.xml file is designed to hold the customization and changes that you want to make to any of the configuration files. The idea is that if you do a fresh installation of a new version, you can simply drop in your existing 100Custom.xml file and all the changes that you have made are picked up and used instead of the default values that you want to put in the 100Custom.xml file.

For example, consider adding any additional columns or views for your task manager to the 100Custom.xml file. Any tuning options, such as for the event manager in the 80EventManager.xml file, are appropriate to put in the 100Custom.xml file. Any changes to default values, such as your system lane user, should be made in the 100Custom.xml file.

Alternatively, if you are changing your database URLs (database name, database machine name, and so on) then consider making those changes directly to the 98Database.xml file. This approach is because these values are written down correctly when you install a new version of the product. 

One note on the 100Custom.xml file changes: When you move to a new version of the product, you always want to review the changes in the 100Custom.xml file to make sure that they are still appropriate in the new version. For example, some of the default settings or database queries that you use in customizing the Process Portal might change between releases. Other settings might no longer apply.

The merge attribute

When you load or replace values using the 100Custom.xml file, you need to be careful which merge setting that you use for each element. The "merge" attribute supports the following:

•       "append" - This setting appends the new tag.

•       "mergeChildren" - This setting merges the new tag with the first of the existing tags, which is the default behavior. In other words the "mergeChildren" setting merges a child element with the parent element. However, the "mergeChildren" setting does not merge a child tag if it does not have any attributes and that child tag only has text.

•       "replace" - This setting replaces all old tags with this new tag.

You can see usage examples for the "append" and "replace" settings in the 50AppServer.xml and 60DataBase.xml files, which overrides things in 00static.xml file depending on the database or application server.

For example, from the sample 100Custom.xml file, you might want to change the <environment-name> value. In the 99Local.xml file you have something like the following code:
<properties>
...
 <common merge="mergeChildren">
   ...
 <environment-name>Environment_from_99Local</environment-name>
   ...
 </common>
   ...
 </properties>

To change the environment name in the 100Custom.xml file, you might use the following code:

<properties>
<common merge="mergeChildren">
<environment-name merge="replace">Environment_from_100Custom
</environment-name>
</common>
</properties>

Making changes to configuration files for a network deployment cluster

For network deployment environments, XML configuration files on the cluster level are templates for XML configuration files that are created when new cluster members are added. If you make changes to the file at the cluster member level (PROFILE_ROOT\config\cells\cell_name\nodes\custom_node_name\servers\cluster_member_name\server_type\config\100Custom.xml), make the changes at the cluster level as well (PROFILE_ROOT\config\cells\cell_name\clusters\cluster_name\server_type\config\100Custom.xml). Making the changes to the templates at the cluster level ensures that the changes are also created on any new cluster member, if one is added in the future.

At run time, only the settings from cluster member files are read. If you make changes after deployment, you need to make them in the cluster member version of the file for each server to have the changes take effect at run time.

Always make changes to any of these XML configuration files on the deployment manager server using the following steps:

1.    Make changes to cluster members, when means that you need to change the XML file for each node. See the path name that is listed earlier in this section, but work in the deployment manager file system.

2.    Make changes to the cluster level to ensure that each new cluster is created with your customized settings.

3.    Select Full Resynchronize to replicate the settings from the deployment manager server to the individual nodes. If you edit these configuration files on an individual node, the changes might be lost in the next update.

Backing up configuration files

It is always a good idea to make a backup copy of the files that you are changing. However, these configuration files are one area where you need to use some caution when backing them up. Specifically, always change the extension from .xml when backing up these files. The following information explains why you want to change the file extension:

All of the files in the .../config directory ending in .xml are loaded by the product on startup. These files are loaded in an alphanumeric order; letters are loaded first and then numbers are loaded in numerical order. For example, if you have the following files in the ../config directory they are loaded in the order shown below:
.../config/system/Copy of 99Local.xml

.../config/system/00Static.xml
.../config/system/50AppServer.xml
.../config/system/60Database.xml
.../config/system/80EventManager.xml
.../config/system/98Database.xml
.../config/system/99Local.xml
.../config/100Custom.xml.

If you want to get more details and explanation about this topic and also about other configuration file, specially TeamWorksConfiguration.running.xml (which is merged file from all xml configuration file created when we start the server), you can go to below links which provides more details.

http://www-01.ibm.com/support/docview.wss?uid=swg21439614

https://www.ibm.com/developerworks/community/blogs/aimsupport/entry/step_by_step_guide_on_changing_ibm_bpm_configuration_files_manually?lang=en

http://www-01.ibm.com/support/knowledgecenter/SSFPJS_8.5.5/com.ibm.wbpm.admin.doc/topics/managing_twks_config_settings.html

Execute a Task in Debug Mode while PD is not available

Get the task ID.
Replace the task id and server host-name in the URL below. 
https://<HOSTNAME>/teamworks/process.lsw?zWorkflowState=1&zTaskId=2078.<TASK ID>&zDbg=1

Different Type of groups in IBM BPM

In IBM BPM, All user groups are stored in LSW_USR_GRP_XREF table. there are different types of group in IBM BPM and they are differentiated by a column 'GROUP_TYPE' in 'LSW_USR_GRP_XREF' table

There are 3 type of user groups in IBM BPM.

1. Groups that exist and managed in external directory services like LDAP. Type 0 Groups
2. Groups that are created in the environment through Admin Console. Type 3 groups
3. Groups that are dynamically created by virtue of task allocation. type 1 and 2 Groups

Groups that exist and managed in external directory services like LDAP

Such groups are created and managed in external directory services like LDAP. Such groups are imported into the BPM database when an user logs in for the first time. Such groups have a GROUP_TYPE as "0" in the table LSW_USR_GRP_XREF. Such groups cannot be edited or deleted through the default Process Admin Console. They needs to be changed from external directory like LDAP.

Groups that are created in the environment through Admin Console.

These groups are created and managed through the Process Admin Console. Since these groups are not represented in the centralized directory services like LDAP, these are purposed to be used inside BPM applications only. These are analogous to TeamWorks logical roles in TeamWorks 6.2. These groups have a GROUP_TYPE as "3" in the table LSW_USR_GRP_XREF.

Groups that are dynamically created by virtue of task allocation.

Groups are dynamically created when a new task is routed to a lane participant (Participant Group) or assigned to a list of users (Ad-hoc group). Dynamic groups corresponding to TeamWorks logical roles are also created during import from a 6.2 environment. These groups are not visible on the Process Admin console, hence cannot be managed. Dynamic groups that are created from Participant Groups or Logical Roles have GROUP_TYPE as "1" in the table LSW_USR_GRP_XREF, where as the dynamic groups crated from list of users have GROUP_TYPE as "2" in the table LSW_USR_GRP_XREF.

After IBM BPM 7511 upgrade old task started from deactivated snapshot failing

Recently we have upgraded to IBM BPM 7511 versino from 7510 and after upgrade we monitored that instances are failing for all the sanpshots which are deactivated. That means if you have started an instance from snpashot 1.0 and then deactivated that snpashot and instance migration was also not performed. All the running instances having referance to snpashot 1.0 will fail.

After investigation we found that it is due to new properties added in 7511.
Business Process Manager Version 7.5.1 Fix Pack 1 added the following new properties:

1. block-deactivated-snapshot-favorite-progression block-deactivated-snapshot-task-progression
2. 
   

These two properties exists in the "99Local.xml" configuration file, are defined, by default, with value "True". This default value for these properties will stop in-flight tasks on the deactivated snapshot.

If you want to process or excute in-flight tasks or instances on deactivated snapshots, you have to change this property to "False"

Note: You do not want to modify the 99Local.xml configuration file directly. Instead, use the 100Custom.xml file to override the values using following steps

To execute these in-flight tasks, complete the following steps: 

1) Locate the 100Custom.xml file.

2) Add the following XML code to the file:

 <properties>
   <server merge="mergeChildren">
     <block-deactivated-snapshot-favorite-progression merge="replace">false
     </block-deactivated-snapshot-favorite-progression>
     <block-deactivated-snapshot-task-progression merge="replace">false
     </block-deactivated-snapshot-task-progression>
   </server>
 </properties>

3) Restart the server.

UCA or Scheduled taks from older version are not beig deactivated - IBM BPM 7.5.1

We have faced this problem earlier and it was very BIG problem for us as the UCA was involved in some very sensitive tasks.

Problem Statement ::
While you install new snapshot for any project and deactivate older snapshot, all older UCAs(scheduled) should be deactivated and only UCAs from new version should be there in Event Manager Queue. but in IBM BPM 7.5.1 this is not the case, All UCAs for older snpashot are still there in Event Manager queue as well as All UCAs from newer version. so basically we have multiple Schduled UCAs for doing same work and executing multiple times.
Earlier we thought like UCAs are executing multiple time but while investigating we realized that its older UCAs which are still there in EM queue.

Solution::
This problem is fixed by IBM and they provided an Ifix for solving this issue.
I-Fix is also included in IBM BPM  7.5.1.1 Fix pack

For more information, 
http://www-01.ibm.com/support/docview.wss?uid=swg1JR41966