LiveCycle ES: start_task=0 in TB_TASK table in LiveCycle database

When you develop a custom interface for an upgraded Adobe LiveCycle ES server, you can encounter problems referencing initial tasks for a process. Initial tasks must correctly show the audit history for processes in your custom interface, much the same as Workspace displays them in the tracking view.

In the TB_TASK table in the database, a start_task flag set to “1” appears for initial tasks from a process started through the TaskManager endpoint. However, for some initial tasks, this flag is set to “0.”

 

This behavior is as designed. Start_task is an ES concept that doesn’t come into play when anything from LiveCycle 7 is involved.  Any tasks migrated from LiveCycle 7, and any tasks started in Workspace with a LiveCycle 7 init-form definition in use, have a start_task value of “0.”

To determine whether a task is an initial task in all cases, locate the task that doesn’t have an action instance. That is, one where the action_instance_id=null or zero. If the process instance ID has a value, but the action instance ID doesn’t, then it’s an initial task.

reference: (181494242)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)

LiveCycle ES: IDPSystemExceptionorigin using DirectoryManagerServiceClient.findGroupMembers()

Issue

When you use the LiveCycle ES API method “DirectoryManagerServiceClient.findGroupMembers()” in a custom application, the following exception may occur:

####<Mar 8, 2010 9:31:28 AM MET> <Info> <EJB> <sunc01126> <wl01ialc01> <[ACTIVE] ExecuteThread: '1' for queue: 
'weblogic.kernel.Default (self-tuning)'> <<anonymous>> <BEA1-0F2A55F8B8D325A5DE0E> <> <1268037088883> <BEA-010051> 
<EJB Exception occurred during invocation from home: 
com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean_jrc290_LocalHomeImpl@ad9846 threw exception: 
com.adobe.idp.common.errors.exception.IDPSystemExceptionorigin: | 
[com.adobe.idp.storeprovider.jdbc.DBObjectSet] errorCode:12290 errorCodeHEX:0x3002 message:nextElement failure| 
[com.adobe.idp.storeprovider.jdbc.DBResult] errorCode:12290 errorCodeHEX:0x3002 message:object update failure| 
[com.adobe.idp.common.infomodel.StoreId] errorCode:12550 errorCodeHEX:0x3106 message:string length wrong
com.adobe.idp.common.errors.exception.IDPSystemExceptionorigin: | 
[com.adobe.idp.storeprovider.jdbc.DBObjectSet] errorCode:12290 errorCodeHEX:0x3002 message:nextElement failure| 
[com.adobe.idp.storeprovider.jdbc.DBResult] errorCode:12290 errorCodeHEX:0x3002 message:object update failure| 
[com.adobe.idp.common.infomodel.StoreId] errorCode:12550 errorCodeHEX:0x3106 message:string length wrong
 at com.adobe.idp.common.util.IDPUtil.raiseIDPSystemException(IDPUtil.java:147)
 at com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean.findGroupMembers(DirectoryServicesManagerBean.java:4261)
 at com.adobe.idp.um.businesslogic.directoryservices.DirectoryServicesManagerBean_jrc290_ELOImpl.findGroupMembers(DirectoryServicesManagerBean_jrc290_ELOImpl.java:1504)
 at com.adobe.idp.um.api.impl.DirectoryManagerImpl.findGroupMembers(DirectoryManagerImpl.java:928)
 at com.adobe.idp.um.dscservice.DirectoryManagerServiceImpl.findGroupMembers(DirectoryManagerServiceImpl.java:238)
 at sun.reflect.GeneratedMethodAccessor1366.invoke(Unknown Source)
 at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:585)

 Solution

  1. Validate the GroupOID string and ensure that it is not the standard Group name, but an identifier of 36 characters.
  2. Validate the members of the group to ensure that they are valid objects. It is possible that one of the members has been corrupted due to manual changes through the API. Remove any corrupt members and re-create them to proceed.

Additional information

The most likely cause of this exception is that there is an invalid GroupOID being passed into the search filter used in the findGroupMembers() method. The OID strings are identifiers with 36 characters. You cannot use the standard Group name for the search filter. You can verify the GroupOID and the members of the group are valid by using the following code:
_____________________________________

DirectoryManagerServiceClient dmsc = new DirectoryManagerServiceClient(myFactory);
Principal group = dmsc.findPrincipal("9462F437-8669-0D04-24F8-F00CDF80A09E");
System.out.println("Group found: "+group.getCommonName());

GroupMembershipSearchFilter gsf = new GroupMembershipSearchFilter();
gsf.setGroupOid("9462F437-8669-0D04-24F8-F00CDF80A09E");

List<Principal> members = dmsc.findGroupMembers(gsf);
System.out.println("Members found:"+members.size());

for(Principal p : members){
 System.out.println("Principal found: " + p.getCommonName());
}
__________________________________________

reference: (181484795)

VN:F [1.9.22_1171]
Was this helpful? Please rate the content.
Rating: 0.0/10 (0 votes cast)