Just the other day I worked very hard on a case that nearly drove me out of my mind.
One of my customers reported an issue that he cannot open a Process Application or Toolkit in IBM Integration Designer (IID). This problem did NOT occur for all Applications or Toolkits, but only for some. At least consistently, so that’s good.
You can imagine that this kind of error blocks the user doing any of their work properly.
The following exception was fired when the user tried to open a sample Toolkit in the IID workspace:
The error message from the workspace .log file and bpmHistory.log was as follows:
!ENTRY com.ibm.wbit.ui 4 0 2016-04-06 04:58:10.982
!MESSAGE Unable to retrieve the list of process applications and toolkits from Process Center. Contact your Process Center administrator for help.
com.ibm.wbit.lombardi.core.exceptions.TeamworksServerRetrieveException: Unable to retrieve the list of process applications and toolkits from Process Center. Contact your Process Center administrator for help.
Caused by: java.lang.NullPointerException
... 4 more
From the exception text the problem is very likely related to
a) A connection problem: Process Center (PC) <--> IBM Integration Designer (IID)
b) A permission problem of user trying to open the Toolkit in IID workspace
So I started my investigation with option two, because in most cases a missing user permission avoids working with PD or IID in a correct way. A quick check, however, confirmed that the user worked with administrator permission. Also the fact that it worked for some Process Apps / Toolkits and for others it did not work did not scream “PERMISSION PROBLEM” – so this was a red herring.
The same holds for a connectivity issue - the connection to Process Center could be established correctly without any failure. The available Process Apps or Toolkits were shown correctly and could be selected. So why is it possible to see all the available Apps and Toolkits, but when the user clicked on one of them and tried to load it into the IID workspace, an exception was fired saying it was not possible to retrieve the list of process applications and toolkits from Process Center? That did not make any sense at all.
Because neither the workspace log output nor the bpmTrace.log provided any helpful clue, our product development team provided a trace patch for a deeper problem analysis.
So, looking at the Process App or Toolkit, I saw that it had a dependency to another Toolkit, as you can see from this recreation sample:
In a standard scenario you can open such a construct without any problems in IID.
That's how it should be.
But what happens when the Toolkit used in the dependency isn't available anymore? What happens when it was archived by mistake and nobody realized it?
In my test I archived the Toolkit (TK_A1, snap2):
As you can see from the two snapshots above, I could archive the snapshot without problems although it was still in use by another active Toolkit or Process App. In the Main TK / Process App there is NO hint or warning that an archived TK is present in the dependencies! Oh dear….
The subsequent test to open the TK in IID workspace failed with the same exception my customer also reported:
The product code checks if a dependency snapshot is a tip, and if it is not, then it checks the archived flag. If it's not a tip and archived, the code skips bringing in the dependency. This leads to the NullPointerException (Caused by: java.lang.NullPointerException) seen in the log output.
I think the most important thing is that Process Center lets users archive a Toolkit that is still in use. At the minimum, there should be a warning that this may lead to unpredictable results. Additionally, the error output is absurd because it routes the user's investigation to a wrong direction.
At the moment, please keep in mind, if a Toolkit is archived and still used in Process Apps or Toolkit dependencies, you may run into such a problem without any previous warnings.
I hope this will help you if you encounter such a situation in the future, and if it does not, take two of these and call me in the morning.