Some customers have reported that a java.lang.NullPointerException is thrown when publishing a project BOM from Rule Designer under certain conditions, such as publishing the BOM to DC over a VPN connection.
Rule Designer workspace log-
!ENTRY org.eclipse.core.jobs 4 2 2021-04-02 15:52:09.098
!MESSAGE An internal error occurred during: "Publish (some_BOM) ".
!STACK 0
java.lang.NullPointerException
at ilog.rules.synchronization.endpoint.remote.client.RemoteRuleModelDataAccess.publish(RemoteRuleModelDataAccess.java:498)
at ilog.rules.synchronization.endpoint.remote.client.RemoteRuleModelDataAccess.saveData(RemoteRuleModelDataAccess.java:724)
at ilog.rules.synchronization.operations.PublishOperation.run(PublishOperation.java:266)
at ilog.rules.synchronization.subscriber.client.AbstractSynchronizationClient.publish(AbstractSynchronizationClient.java:175)
at ilog.rules.synchronization.eclipseui.operations.PublishSynchronizeOperation.run(PublishSynchronizeOperation.java:186)
at ilog.rules.synchronization.eclipseui.operations.SynchronizeOperation.run(SynchronizeOperation.java:128)
at org.eclipse.team.internal.ui.actions.JobRunnableContext.run(JobRunnableContext.java:144)
at org.eclipse.team.internal.ui.actions.JobRunnableContext$ResourceJob.runInWorkspace(JobRunnableContext.java:72)
at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38)
at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54)
Decision Center log-
[4/2/21 15:52:02:149 CDT] 000001a5 MessageHandle E Exception examining incoming message.
java.lang.NullPointerException
at ilog.rules.teamserver.web.servlets.AbstractRtsServlet.unmarshallMessage(AbstractRtsServlet.java:158)
at ilog.rules.teamserver.web.servlets.RtsSyncServlet.doPost(RtsSyncServlet.java:196)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:595)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
While the conditions and root cause of the exception have not yet been determined,
there are some workarounds to allow the BOM changes to be published to DC when bypassing the VPN connection is not possible.
1) The simplest method is to manually export the BOM.zip from Rule Designer and manually import it into Decision Center Business Console, thereby avoiding the synchronization process entirely.
2) To workaround the NPE and use the synchronization/publish feature (likely only needed when VPN network connection is used) is to apply specific BOM changes to the b2x file from the Rule Designer project workspace, then attempt to publish the BOM to DC again. This involves a minor java code change to the member constructor, to use a package import where the member constructor returns a FQN BOM class name and replace it with just the BOM class name (without FQN class).
An example using the java.util package is shown here.
Before change-
<b2x:translation xmlns:b2x="http://schemas.ilog.com/JRules/1.3/Translation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.ilog.com/JRules/1.3/Translation ilog/rules/schemas/1_3/b2x.xsd">
<id>9aa64224-127a-4766-91dd-d6f11ee99cc8</id>
<lang>ARL</lang>
<class>
<businessName>java.util.SortedSet</businessName>
<constructor>
<body language="arl"><![CDATA[
return new java.util.TreeSet(); ]] >
</body>
</constructor>
</class>
</b2x:translation>
In this case, the NPE was caused by using a FQN class in "return new java.util.TreeSet()" statement when publishing the BOM from Rule Designer over a VPN connection to DC Server.
After workaround changes applied, the .b2x file would look similar to this-
import java.util.*
<b2x:translation xmlns:b2x="http://schemas.ilog.com/JRules/1.3/Translation"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://schemas.ilog.com/JRules/1.3/Translation ilog/rules/schemas/1_3/b2x.xsd">
<id>9aa64224-127a-4766-91dd-d6f11ee99cc8</id>
<lang>ARL</lang>
<class>
<businessName>java.util.SortedSet</businessName>
<constructor>
<body language="arl"><![CDATA[
return new TreeSet(); ]] >
</body>
</constructor>
</class>
</b2x:translation>
Note: this example shows the code pattern of a BOM that relied on a
FQN class name for a method from java.util.* package. The code pattern could be from any java package where a method returns a FQN class name used as inline code rather than relying on the package import statement for the FQN and the method returns only the classname.
It's also worth noting that the same unmodified BOM code with a FQN class name used as inline code may actually publish successfully when "on-premises" and not over a VPN "network tunnel" connection, however this is not confirmed for all of the reported incidents.
#OperationalDecisionManager(ODM)#Support#SupportMigration