Loading Drools Rules from database during JBPM server load up - drools

We are using jBPM for our process flow needs. However, this jBPM process is triggered via REST APIs from our Java code. Thus,
Java App had application code and we trigger the jBPM process from here using APIs.
jBPM instance( JBPM 6.1 ) is being used for the process flow execution. This instance is also there but is accessed remotely.
Now, we are trying to integrate the Drools engine for our business rules needs. What we want is that we will store all our rules in the database and these rules will be loaded when the JBPM server starts up( or when the Java VM boots up). Thus, the rules will be loaded into the working memory and be available for use in the JBPM process when needed.
2 questions here:-
1) How do we get this done ( loading rules from the database and getting them into the working memory of JBPM and Drools right when the JBPM server loads up)?
The idea is that once the rules are loaded, they can be accessed anywhere in process as needed.
Also, if we wanted to update the jBPM variable with the value obtained from the Drools rules what were loaded earlier, how can we do that ?

At startup, you can do this by loading the resources from the database and converting the strings to byte arrays and creating the knowledge base:
Resource workflowResource = ResourceFactory.newByteArrayResource(workflowBpmnByteArray);
Resource rulesResource = ResourceFactory.newByteArrayResource(resourceByteArray);
KnowledgeBuilder knowledgeBuilder = KnowledgeBuilderFactory.newKnowledgeBuilder();
knowledgeBuilder.add(workflowResource, ResourceType.BPMN2);
knowledgeBuilder.add(rulesResource, ResourceType.DRL);
KnowledgeBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration();
KnowledgeBase knowledgeBase = KnowledgeBaseFactory.newKnowledgeBase("knowledgeBase", config);
knowledgeBase.addKnowledgePackages(knowledgeBuilder.getKnowledgePackages());
Remember that adding resources to the knowledge builder will cause them to be compiled so you should check for errors before creating the knowledge base.
The resulting knowledge base can be cached in memory and used for creating process instances within your application.

Related

spring data geode pool is not resolvable as a Pool in the application context

I've come back to a #SpringBootApplication project that uses spring-geode-starter with version 1.2.4 although the same error happens with upgrades to 1.5.6 version.
It sets up a Geode client using
#Component
#EnableClusterDefinedRegions(clientRegionShortcut=ClientRegionShortcut.PROXY)
and in order to register interest subscriptions over HTTP, also
#Configuration
#EnableGemFireHttpSession
with a bean
#Bean
public ReactiveSessionRepository<?> reactiveSessionRepository() {
return new ReactiveMapSessionRepository(new ConcurrentHashMap<>());
}
On starting the application the spring data geode client connects to the server (Geode version 1.14) and auto copies regions back to the client, which is great.
However, after all the region handles are copied over, there's an error with the #EnableGemFireHttpSession which is
Error creating bean with name 'ClusteredSpringSessions' defined in class path resource [org/springframework/session/data/gemfire/config/annotation/web/http/GemFireHttpSessionConfiguration.class] and [gemfirePool] is not resolvable as a Pool in the application context
The first info message in the logs is:
org.springframework.session.data.gemfire.config.annotation.web.http.GemFireHttpSessionConfiguration 1109 sessionRegionAttributes: Expiration is not allowed on Regions with a data management policy of PROXY
org.springframework.data.gemfire.support.AbstractFactoryBeanSupport 277 lambda$logInfo$3: Falling back to creating Region [ClusteredSpringSessions] in Cache [Web]
So the client is trying to create a region ClusteredSpringSessions but it can't. The problem appears to resolve itself if I define a connection pool for HTTP, with a pool connection bean like this
#Configuration
#EnableGemFireHttpSession(poolName="devPool")
public class SessionConfig {
#Bean
public ReactiveSessionRepository<?> reactiveSessionRepository() {
return new ReactiveMapSessionRepository(new ConcurrentHashMap<>());
}
#Bean("devPool")
PoolFactoryBean sessionPool() {
PoolFactoryBean pool = new PoolFactoryBean();
ConnectionEndpoint ce = new ConnectionEndpoint("1.2.3.4", 10334);
pool.setSubscriptionEnabled(true);
pool.addLocators(ce);
return pool;
}
}
There is still the Expiration is not allowed on Regions with a data management policy of PROXY info message in the log, but this time the Falling back to creating Region [ClusteredSpringSessions] in Cache [Web] appears to work.
I don't understand why a default pool can't connect.
If a pool is defined then in version 1.2.4 that can cause this issue.
Since you are using Spring Boot for Apache Geode (SBDG), which is an excellent choice (thank you), then you can simply include the spring-geode-starter-session dependency on your #SpringBootApplication classpath, which removes the need to explicitly annotate your Spring Boot application with SSDG's #EnableGemFireHttpSession annotation.
See here for more details. I also have a Sample application demonstrating the use of SSDG, here. The guide and source code for this example, along with other examples, can be found here).
Also, I would generally advise that users drive the GemFire/Geode cluster configuration from the application and not let the cluster dictate the Regions (and/or other components/configuration) that the client gets. However, SDG's #EnableClusterDefinedRegions annotation is provided and generally useful in the case you do not have control over the GemFire/Geode cluster your application is using. Still, in the (HTTP) Session UC, the GemFire/Geode cluster would need a Session Region (which defaults to "ClusteredSpringSessions" as determined by Spring Session for Apache Geode (SSDG) itself) anyway.
OK, now to the problem at hand...
I think what is happening here is, due to backwards compatibility and legacy reasons, Spring Data for Apache Geode (SDG), on which both SSDG and SBDG are based; SBDG additionally pulls in SSDG as well, defined a GemFire/Geode Pool by the name of "gemfirePool", specifically when using the SDG XML space and using/defining a DataSource configuration.
So, it is somewhat naively assumed users would be explicitly defining a Pool and calling it "gemfirePool", and not simply relying on a "default" Pool connection to the GemFire/Geode cache server (namely "localhost", 40404, or if using Locators (recommended), "localhost" and 10334).
However, for development purposes, and in SBDG specifically, I rely on the fact that GemFire/Geode creates a "DEFAULT" Pool anyway (when no explicit Pool is defined), and forgo the strict requirement that a "gemfirePool" should exist. But, SBDG builds on SSDG and SDG and they still rely on the legacy arrangement (for example).
I have filed an Issue ticket in SSDG to change this and better align SSDG with what SBDG prefers going forward, but I simply have not gotten around to it yet. My apologies for your inconvenience.
Anyway, it is a simple change you can make externally from your Spring Boot application, in application.properties like so (see here from the HTTP Session Sample I referenced from SBDG above). This will allow you to configure the Session Region Pool "name".
Also note, it is possible to change the name of the Session Region used by the client if what comes down from the cluster when you are using SDG's #EnableClusterDefinedRegions and the Region definition pulled down from the cluster is named differently on the server-side using this property.
Additionally, you can also configure the client Session Region data policy using properties as well (for example).
Regarding the Expiration "info" message you are seeing in the logs...
Since the client Session Region is a PROXY by default, then Expiration, Eviction and other Region data management policies (e.g. Compression, etc), do not actually make much sense.
In fact, SSDG is smart about whether to apply additional Region data management policies locally or not (see here, and specifically, this logic).
The message you are seeing in your application logs is in fact coming from SSDG, specifically. This message really serves as a reminder that your Session state management is actually "managed" on the server-side (when the application client is using a PROXY or even a CACHING_PROXY Region for that matter) and that the corresponding server-side, or cluster Sessions Region should be configured manually and appropriately, with Expiration policies as well as other things if necessary. Otherwise, no Session expiration would actually happen!
I hope all this makes since.
If you continue to have problems, feel free to file an Issue ticket and provide an example test or small application replicating your problem.

Agile Classes.jar file

I am using Agile PLM Version: 9.3.0.2 (Build 20). I am on the client side. I'm trying to use Eclipse to interact with Agile's API features. According to the Agile SDK Developer Guide I need both:
AgileAPI.jar
agileclasses.jar
I have the AgileAPI.jar file, but I don't have the agileclasses.jar file.
Any suggestions/links/ methods in which I can obtain this file!
AgileAPI.jar, contains the factories and interfaces used by the Agile EJB on server side.
If you have an Agile instance on a server, you don't need to have agileclasses.jar (unofficial API) but creating an IAgileSession using AgileSessionFactory, all the implementation of interfaces (IChange, IPrograms, IItem. etc) are retrieved using it.
session.getObject(IChange.OBJECT_TYPE, "ChangeNumber123");
where did you find that agileclasses.jar is required?
However, you can find them in the Weblogic Server shared lib folder.
EDIT
Eclipse interacts with an Agile Server using AgileAPI.jar.
String server = "http://myServer:7001/Agile";
HashMap<Integer,String> params = new HashMap<Integer, String>();
AgileSessionFactory instance = AgileSessionFactory.getInstance(server);
params.put(AgileSessionFactory.USERNAME, "myUsername");
params.put(AgileSessionFactory.PASSWORD, "myPassword");
IAgileSession session=instance.createSession(params);
IItem item = (IItem) session.getObject(IItem.OBJECT_TYPE, "ITEMID1234");
item.setValue("Page Two.MYFIELD", "Value");
The example above, connect to an instance of Agile (server) already started up and get the item with number ITEMID1234. Then it sets the value of a field (MYFIELD) with "Value"

jbpm 6.0.1 create process calling rest

How to create process with 1 service task - rest which calls
http://www.webservicex.net/currencyconvertor.asmx/ConversionRate?FromCurrency=EUR&ToCurrency=USD
and sets this value as parameter which can be seen later, using jbpm console(kie workbench)? JBOSS docs are mostly for user tasks.
My recommended solution is to create a new WorkItemHandler implementation that calls the web service get the results and inject that as a process variable.
You can see a similar example that calls web services here: https://github.com/droolsjbpm/jbpm-playground/tree/master/customer-relationships-workitems
HTH
There is a REST service task that you can use, available out-of-the-box in the web-based designer (under service tasks, so implemented as a custom service task). The associated handler should also be registered automatically when using the jbpm-installer:
https://github.com/droolsjbpm/jbpm/blob/master/jbpm-installer/conf/META-INF/CustomWorkItemHandlers.conf#L4

Best way to store Database configuration parameters?

I'm developing a web application at the moment. The web application needs to access a Patients database, which for now is a simple MySQL database but may likely be replaced by some other DB (or data source) in the future. At the moment, everything is hardcoded but I would like to have some way to configure the DB connection (that is, the database URL, user, password etc.).
What would be a simple and straightforward solution? It would be good if I could change the configuration by simple editing of a file.
I've seen there's the Properties API as well as Preferences. Or is there some idiom concerning servlets/web apps?
A servlet is part of a web app, and this web app is deployed in a Java EE container (Tomcat, WebLogic, etc.).
The standard way to get a database connection is to use JNDI to get a DataSource instance, and to ask a connection to this DataSource. The DataSource, most of the time, will pool database connections to avoid creating and closing too many connections and thus be much faster :
Context initCtx = new InitialContext();
DataSource dataSource = (DataSource) initCtx.lookup("java:comp/env/jdbc/MyDataSource");
Connection c = dataSource.getConnection();
try {
// ...
}
finally {
c.close(); // makes the connection available for a new thread
}
The DataSource will have to be declared in the web.xml file:
<resource-ref>
<description>Datasource example</description>
<res-ref-name>jdbc/MyDataSource</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
It will have to be defined (with its URL, number of connections, user, password, settings, etc.) inside your Java EE container. This is where it depends on your container.
Read the following explanations for Tomcat : http://tomcat.apache.org/tomcat-7.0-doc/jndi-datasource-examples-howto.html
I think a configuration XML along with your web application is a good idea. Each time the application is initiated by a new request the configuration is loaded and the database connection information available from any internal context that you make.
On IIS this is a standard way through the Web.config file.
regards

Upgrading from DeploymentService to ProfileService in JBoss 5.1.0 GA

In Jboss 5.1 the Profile Service does what the Deployment Service was doing in Jboss 4.x.In Jboss 4.x I was using the Deployment Service to create a datasource "on-the-fly" and I was wondering if I could do the same thing using the Profile Service (since Deployment Service doesn't exist any more in Jboss 5.x).
Does anyone know a practical guid on using ProfileService?
Thank you ,
Regards.
I don't know of any guide but I can provide you with my experience using the Profile Service and a few links to JBoss wiki pages on this topic. I'd like to post more links but the spam protection doesn't allow me to post more than two, but you should easily find the other pages in the wiki on the ProfileService. Don't be suprised in case you don't find much, there isn't more.
ProfileService ManagementView
http://community.jboss.org/wiki/ProfileServiceManagementView
ProfileService DeploymentTemplates
http://community.jboss.org/wiki/ProfileServiceDeploymentTemplates
There you'll find usefull information about the ProfileService but no detailed information is available in the jboss wiki as far as I can tell.
In order to create Datasources on the fly you can use the DeploymentTemplates (also for creating message queues and topics) The last link provides you with information on how to use the templates but not with all the template names and their properties. You can list them programatically though.
// Get all Templates
for(String template : mgtView.getTemplateNames())
{
System.out.println("=========================================");
System.out.println("Listing properties for template: "+template);
DeploymentTemplateInfo info = mgtView.getTemplate(template);
for(String prop : info.getProperties().keySet())
System.out.println("- "+prop);
}
In order to get the ManagementView (mgtView) from an external java programm you can use something similiar to this:
// set security policy
System.setProperty("java.security.policy", "<path_to_policy_file>");
System.setSecurityManager( new RMISecurityManager() ) ;
// set initial context properties
Hashtable<String, String> env = new Hashtable<String, String>();
env.put("java.naming.factory.initial", "org.jnp.interfaces.NamingContextFactory");
env.put("java.naming.provider.url","jnp://localhost:1099");
env.put("java.naming.factory.url.pkgs","org.jboss.naming:org.jnp.interfaces");
ctx = new InitialContext(env);
// login to JBoss
SecurityClient client = SecurityClientFactory.getSecurityClient();
client.setSimple("admin", "admin");
client.login();
// get ProfileService and ViewManager
ProfileService ps = (ProfileService) ctx.lookup("ProfileService");
mgtView = ps.getViewManager();
What you want to get is the Java Naming Conext (InitialContext). In order to do that you'll need a security policy (you can use the java.policy file which is located in JBOSS_HOME/server/SERVER_DIR/conf/),security manager and environment properties to get the context. The java.naming.provider.url specifies the location of the JBoss naming service (default port is 1099).
Usually you would have to authenticate at this point which is done with the SecurityClient.
Finally you can use the context to grap the ProfileService.
At this point most of the anoying stuff is done und you can start playing around.
getViewManager() returns the ViewManager with which you can create datasources on the fly and getDeploymentManager() will give you the DeploymentManager with which you can deploy, undeploy, start, stop applications and other deployments.
The libraries you'll need to do that are located in
JBOSS_HOME/client
JBOSS_HOME/lib
JBOSS_HOME/common/lib
I've read several times that including the jbossall-client.jar in the client directory should be enough but that's actually not true. You need libraries from all three directories as far as I can tell (couldn't do it without referencing all of them at least). I haven't figured out which exact jars you need though...
IMPORTANT: The ProfileService in Jboss 5 Community Edition has some bugs though which got fixed in JBoss 6. I'd either suggest using a newer JBoss version or the Enterprise Edition.