Now, in this case here, when the new version of the Process Application was deployed to TEST, the pivot table was not dropped and recreated, hence it was out of synch.
This could be easily fixed by dropping and recreating the tables.

This week, I found something interesting. While the official fixlist for BPM 8.5.5 states that the iFix for JR50008 - MALFORMEDURLEXCEPTION OCCURS WHEN YOU ACCESS A MANAGED ASSET FILE - is included, the "versioninfo -long" command output run on any v8.5.5 system does not show it listed.

After some research I found, that JR50008 is not included in v855 and it is accidentally listed in the fixlist for this product version. We are working on getting this corrected.

If you need this fix on v855, you may simply install iFix JR50653 for v855. It does contain the code change for JR50008 and is available for v855.

And if JR50653 does not help you, take two of these and call me in the morning.

Here an interesting read that our community member O.J. sent in. Thank you O.J. for your contribution. This is good to know!

Enjoy this read,

Yours
Dr. D

Environments updated to BPM version 8.0.1.3 or 8.5.6 may have issues in the Process Portal or in a custom-written Coach, where data is not displayed as expected. Related SystemOut.logs will show:

[31/03/15 16:33:52:855 BST] 0000015a CallServiceAc E The servlet, callservice.do, is not configured to call Example; configuration option
"callservice-valid-services" is not configured to call services of type General System Service.

This is due to APAR JR50215 which is included in BPM 8.0.1.3 and 8.5.6
Because there is no access restriction based on service type when invoking a service using the callService URL, services that were meant for internal use only are exposed.
The fix enables administrators to restrict callable services by type. The fix is secure by default and only allows AJAX services to be invoked via the callService.do URL. If you have custom client applications relying on callService.do exposing service types other than Ajax Services, you need to add configuration as described below.

Edit your 100custom.xml to contain desired service screening. Administrators are given the ability to change this to allow any permutations of different services that will be allowed.
Be advised that opening multiple services to be executed by callService.do will introduce a possible security issue. In fact, even AJAX services could be used for an attack by an authenticated user, given they know specifics about the service.

Service developers should redesign any potential services to use something that will not be allowed to be executed.

If the <callservice-valid-services> tag is not added to 100custom.xml, Process Portal will default to only using AJAX services. Should you need to invoke callService.do to launch a service, you need to ensure there is a <valid-service-entry> tag (inside the <callservice-valid-services> tag) containing the type of the service you need to launch. An example to only run integration services is shown below:

Users may use any permutation of the service ID to allow specific types of services to be executed by callService.do.
Another example would be shown below, which will block everything except for Regular Services, AJAX Services, and SCA Services.

A few days ago, I was presented an interesting issue. One of my customers experienced an unacceptable wait problem while starting their BPM AppCluster.
As always, the first step is to look at the SystemOut.log to see, if there is anything interesting in there.
In this case, there were a vast numer of DB queries, similar to this:

select data,version_id from lsw_bpd where version_id in (select distinct ver.po_version_id from lsw_po_versions ver inner join lsw_snapshot snap on (ver.branch_id=snap.branch_id and ver.start_seq_num<=snap.seq_num and ver.end_seq_num > snap.seq_num) where ver.po_type=25 and snap.name is not null)

Yep, yet again another Performance debugging.

As my customer mentioned the delay starts right then, when cache settings were loaded, I checked the SystemOut.log for anything Cache related during the start-up.

I found the following line:

000000ae wle I CWLLG2155I: Cache settings read have been from file file:

As you can see, the threadID for that activity is 000000ae. So I grepped for 000000ae to see the whole thread.

And I was quite surprised to see a !9 MINUTE! delay in the start-up. You know, most of the performance cases we see are on a very high level, meaning we are talking of improvements of a few seconds. But this one, I have to tell you, had a good point. Now 9 minutes is an awefully long time to wait. 9 minutes - that is about 2 cups of coffee. Too long, as you will most likely agree.

From the information in the logs it seemed that the delay was related to the Cache, as it occured between the cache settings being loaded and the cache being initialized.

So, where could this be coming from? Maybe some slow DB causing this delay? Well, we do not yet have enough information to tell, hence we need some traces.

This APAR was introduced for BPM 7.5.1.2 with a new property named <use-business-aliases-for-process-instances>.
The default value for that property is " T R U E ".

TRUE means that the list of searchable Business data aliases are returned only when they are used in actual process instances.

If FALSE is selected, the Business data aliases will be created at the server startup already BEFORE the first access by process instances. If there is a large number of BPDs, searching all the BPDs can take a very long time.

The more process applications are deployed on server the more aliases will be created, the longer the cache load time takes.

So, if this was introduced in 7.5.1.2 why did I still see this in 8.5.5? APAR JR47818 is part of BPM v8.5.5.

Hm, what could have happened here?

As my grandmother would have said: Never trust a running config (if she had known what a running config was). Hence lets have a look at the 99local.xml file on my BPM 8.5.5 setup to verify the default configuration for that attribute.

Indeed, the value is set to " F A L S E " !

Checking the customer's 99local.xml and 100Custom.xml showed the same.