MongoDB and Bonita BPM: Power-up Process Applications

The first thing I’m gonna do is I’m gonna go through a quick refresh about what RDBMS are (Relational Database Management Systems) and we’re gonna go and deep dive into the subject. We’re gonna explore NoSQL databases and we’re gonna look at that with MongoDB in mind. Then next point, I’ll be exploring the differences between NoSQL databases and the traditional relational databases and in conclusion, the integration of MongoDB with Bonita BPM.

First, let’s start with this quick refresh about what is an RDBMS? RDBMS stands for Relational Database Management Systems. These are actually the oldest types of DBs available on the market; these stay back for as long as the 70’s and because of their age, they are the most widely used systems also in the industry.

There’s a tendency to confuse them with SQL databases and that’s more or less the same thing because most of the databases that are relational implement the SQL standard. SQL stands for Structured Query Language.

Anyway, they are relational because they store data in tables. These tables are bound to a schema. That’s a structure that where there are attributes and they’re linked by relations.

So what we have is for each table we have a primary key identifying your table row with a unique ID and we have maybe some foreign keys relating to some other tables and this is called a relationship.

In the diagram on the screenshot above is the relationship between table A and table B. This is a relational database that we have here.

We’re gonna go into the subject. We’re gonna talk about NoSQL databases.

NoSQL databases are something that are really getting popular right now but they are not exactly brand new. They tried to appear in 2000. Few people might actually get why they are called “NoSQL”… They are so-called NoSQL because they are in fact not only SQL and generally, they do not expose the traditional SQL interface.

So, they have another language to interface themselves to connect data. The appropriate term would rather be in fact, NoRel databases because generally, these NoSQL databases are in fact Not Relational. So, it’s not exactly the fact that they are not SQL that is interesting; it’s the fact that they’re not relational.

NoSQL is actually a pretty broad term. We’ll see that there are actually different types of NoSQL databases. Actually, there are more than 4 but here we’re gonna present the main types.

We have column stores. Here, you may have heard of Cassandra and HBase. So, these rely on columns containing data.

We have document stores. This is what is gonna be interesting for us in this webinar when we talk about MongoDB, that’s one of the example of document stores. We also have Couchbase; that’s also a pretty popular document store.

Then, we have key-value stores like Redis or FoundationDB.

Lastly, we have graph-oriented database management systems. We have Neo4j and OrientDB.

So, there are many different types of NoSQL databases and they really don’t behave the same; they don’t tend to address the same functionalities in the same manner.

What we’re gonna do now is we’re gonna continue with MongoDB in mind. We’re not gonna cover all the type of NoSQL databases. We’re gonna go with document store with MongoDB in mind.

First, why are we talking about MongoDB? There are 3 main reasons why we have selected MongoDB to present NoSQL databases.

First reason is that it’s open-source license. It’s the leading NoSQL database management system and it’s pretty flexible, it has a good documentation.

I’m gonna blab a bit at this point to explain why in detail we have chosen this database. The first reason, MongoDB is open source. As you already know Bonitasoft is an open-source company so we strongly believe in the open source model. We really wanted to put that to emphasize and promote the use of open source technology and we are actually not the only ones to believe in open source technology.

The graph that you see here is the popularity balance that was generated by a website called DB-Engines.com and let me give you a bit of background on the data that you see here. This site DB-Engines.com compares all the possible database that exists on the market. They have registered something like 233 databases and they are collecting data with search engine trends on Google, Bing. They are also collecting technical forum trends on things like cycle overflow or DB stock exchange. They are also collecting data from job offer sites like indeed, simply hired and they are also scanning social and professional networks like Twitter and LinkedIn. So, they are really scanning the logger data and base on this data they have established some rankings.

The figure you see in the screenshot is taking account the comparison of the databases that are using open source technology or using commercial closed source technology. And what you can see here is that during the last year, the interest in commercial license solutions has dropped actually and it has continually dropped right now. In the meantime, of course this is replaced by open source so that’s really a big increase in the open source interest. So as I said, everybody is interested in open source and MongoDB is one example of open source so, that’s one of the reasons why we chose it.

Another reason, I think it’s even more important than the fact that MongoDB is open source is that it is becoming the leading database management system. Still using the figures from DB-Engines and looking at the popularity, this new graph shows the popularity rating of the different database systems.

What you see here actually is that if I take only the top 7 databases that are registered out of the 233 databases, MongoDB rates actually number 5 and it’s the number one NoSQL database in all the database that we checked in DB-Engines.com.

Of course, it’s still pretty far from the major players. You can see the top 3 ones here: Oracle, MySQL and SQL server but if you look at the graph, you see the bluish line actually that is at the bottom in November 2012, you can see it’s really rapidly growing in terms of popularity and it’s reaching almost number 4 position. It’s really exceeding all the other oldest players like Postgres or DB2, Access. It’s really really gaining in popularity. So, I think it’s a good reason that we should talk about this one.

The last topic here is more for taking copeople. This implementation of the NoSQL database is pretty flexible. It had a really good documentation and there’s actually a wide variety of drivers that they have put in the list and they have 12 languages in which MongoDB can interact with. It ranges from C, C++, C#, Java, Node JS, Perl, PHP, Phyton, Ruby, Scala and Go. So, lot of different languages in which you can interact with.

There’s also a complete documentation. There’s a lot of different tutorials and there are also some pretty detailed use cases about how to achieve this particular solution, how to achieve this other solution.

Lastly, there’s really a very active community that is related to this technology. There’s a lot of discussions going on, lot of knowledge transfer going on and there is also a lot of contributions. Some of the drivers are actually supported by the community, so that’s a pretty good sign. Meaning it’s a really dynamic technology because people invest their own time to give knowledge and to give more powers to the community by creating themselves drivers.

These are the reasons why we chose MongoDB.

Now, let me talk a bit more about what MongoDB is. How does it work? I have said that MongoDB is a document store. It’s really one of the different database types that are existing, NoSQL.

What document stores mean is basically data is stored in what we call a Collection of Documents. So, what we have is on the first level is a database that can contain multiple collections and for each collection we have documents. If I can draw a parallel with a traditional relational database, a collection would be a table and the document would be a row within the table but we’re gonna see soon in the next couple of slides that it’s really not the same thing.

Documents are represented in BSON. BSON means Binary serialized JSON and in the screenshot is the textual representation. You have an object with an id attribute with value 1, firstName attribute value “John”, lastName attribute value “Doe”. This is a document. It looks like more or less a traditional relational database.

Now, we’re gonna delve into the power of NoSQL. There’s actually something a traditional relational database cannot do, these are having an embedded data and arrays.

The document we have in this screenshot shows you again the same object with id, firstName and lastName and it shows you that you can use embedded objects. Here, you can look at the homeAddress object that contains attributes so we have actually like a document within a document.

This person object contains the homeAddress object and this homeAddress already has some attributes like the number of the street and the street name and whatever other attributes you can have. It could also have other sub objects, so you can embed objects into each other. You can create a relational view of properties within your document.

Another thing you can do also is to store arrays within a document and here the last attribute of this document is called nicknames. So for nicknames, you could have a list of different values.

Typically if you wanted to implement this using traditional relational database, you would have to create multiple tables; you have to have foreign keys. It will be a whole different structure. Here, you can fit all of these data into a single document. So that’s really one big difference here with traditional relational databases.

Another huge difference is the fact that we have a flexible schema. If you talk about a relational database, you have an imposed schema but here, you don’t need to define a schema. So you don’t impose a structure at the collection level and what happens is that at anytime, you can change the data of your document and you can add a new attribute or remove existing attributes.

Another thing also that is quite interesting is that you don’t need to have the same structure for all documents in a collection. In the example I show here, I have a product collection.

The first document of my collection is a movie and it has an attribute called director. Next to this, I could add another document to my collection, another document with another type. For example here, I have a book and this book doesn’t have the attribute director. I don’t need it; there’s no director for a book. So instead I have another attribute called author.

So, I can mix different documents with different structures within the same collection. Of course, there is still a sense of a shared schema because both of them are really products. They still share some attributes but you can have really more specific attribute that exist only in certain documents. So, this gives you great flexibility. This is the high level view of MongoDB I want to give you. We’re gonna see more when we’re gonna play with it.

Let’s get back to the topic of comparing NoSQL databases with traditional relational database management systems.

We’re gonna compare those types of database with 3 big topics. Looking at the main advantages of NoSQL database, the first one is that we have denormalized data in NoSQL databases.

Then the second point is that we have better read/write performances if you know SQL databases. And lastly, we have also a great horizontal scalability. So, I’m gonna develop these 3 points and give you a bit more insight in these 3 different topics.

To continue on the data aspect, we have what is called denormalized data. We’ve seen that we have a flexible schema and this is very good for developers because it gives you some extra agility.

If at any point during the project you discovered you’re missing an attribute, you don’t have to refactor the whole table or you don’t have to refactor your whole schema. You can adapt live to changes of a specification. It gives you lots of flexibility and you can enrich your schema while the DB is running; you don’t need to do migrations or stuff I’ve asked using NoSQL database.

Another point that is really interesting with denormalized data is that you don’t necessarily need to do multi-table queries once you have denormalized data.

When we are looking at hierarchical data, you don’t need to do queries running across different tables because everything you need might be stored inside a single document. This actually leads to our second point, read and write performances.

Because we have this flexible document structure, we don’t need to do costly join operations. So, if you’ve been playing a bit with database and talking to database administrators, you may know for a fact that this is the costliest operation when you do complex queries, you have joins basically relating several tables together to achieve a single result. So this join operation in traditional relational databases is something very costly and with our flexible schema in NoSQL database, you can get rid most of this join operations. So, that’s really a good thing for performance in reading the data.

Same thing for reading and writing, we have another thing that is really critical in terms of performance. There’s no support or limited support for ACID properties when you do read/write to a NoSQL database. As a reminder, ACID stands for atomicity, consistency, isolation and durability. Basically, these are some properties that guarantee stability of data when you deal with transactions and live operations. This is generally something that is really enforced in relational databases but it’s not too much enforced into NoSQL databases so this means that there’s basically less shaking that occurs when you read and write data to the NoSQL database so it goes much faster.

And last main advantage of NoSQL database is that we have a great horizontal scalability. There are two main things you can do with a NoSQL DB: you have clustering and sharding.

The first topic clustering means that we can replicate data across several servers. With that we can achieve high availability and we could achieve also high performance. This is something also that traditional relational database can achieve but generally, this is not something trivial to do with a relational database system. This is something that means extra cost, extra complexity in terms of architecture that NoSQL database are designed and ready to be clustered. That’s really something that has been implemented in their specification by nature and so they’re much better tooling to do that.

Same great advantage of NoSQL databases is that they support sharding. Sharding means that you can partition your data across several servers. So, imagine you have a big library. You could put all your books ranging with a title from A to F on the first server, the other books ranging with the title from E to J on the number 2 server and etc. You could partition your data on different servers and this is not something that is generally possible with relational databases. This is something very specific to NoSQL databases. So when the volume of data increases, these are really some big advantages of using NoSQL databases.

Up ‘til now, I have given you a lot of advantages and really some powerful features of NoSQL databases but there are also some limitations and here, we’re gonna give you the main limitations that they carry.

The first limitation I’ve been briefly talking about is that NoSQL databases generally do not support transactions and they do not have integrity constraints. I’ll be talking about that when I talk about ACID properties. So, these databases generally rely on the applications that feed them data to provide some consistency in the data they feed or they have some fall-back mechanisms if some operations are interrupted. So, you have to implement some keen approaches, some checks but generally the NoSQL databases do not have transaction.

For those of you who don’t exactly know what a transaction is, basically this is something that ensures that an operation is complete or is completely cancelled if an error occurs during the transaction. Typically, if we have a bank account and we want to transfer money from one account to another, we start by subtracting money from the source account and then adding money to the target account but if anything goes wrong during these two operations, we can revert and go back to the original stage. That’s called a roll-back and with NoSQL databases, we cannot achieve that.

You can still have some work around to do that but it’s not as easy as it would be using a traditional relational database management system. So, this is really a blocker for certain applications typically finances. As I gave you the example with money transfers, it is not acceptable to lose money because we lost part of our data or the transfer was incomplete. So, that’s one of the main hindrance.

Another limitation of NoSQL databases is even if they’ve been running from the beginning of 2000 is that it’s a pretty new technology and up ‘til now, there are really too many vendors on this market. There’s a lot of different projects, lots of different technologies, not everybody is gonna succeed; there’s too many technologies so at some point, some of them will fade. It’s gonna be a tough choice to choose the right vendor when you start a new project.

And another thing is if you start a project with a specific technology, it’s gonna be really difficult if you’re gonna switch maybe for the reason of technical limitation. If you switch to another technology, it’s gonna be difficult because there is no standard yet. If you talk about relational databases, we have at least the SQL standard but for NoSQL, there’s no written standard. So, what I was saying here it’s a new technology, so basically choosing a vendor means a project risk. You’re gonna stick with this vendor for a long time so you wanna make sure you choose the right vendor and this vendor provides a solution that meets all your criteria. So, it’s really such a good choice here. This is why actually we’re gonna talk about MongoDB is that we’ve shown this particular vendor is not gonna disappear any time soon ‘cause of its popularity and its features.

Lastly, just to finish my comparison between the traditional relational databases and NoSQL database, I’m gonna illustrate that through a theorem called the CAP theorem. CAP stands for consistency, availability and partition-tolerance and just to give you a bit of explanation about what these terms mean…

Consistency means basically is data coherent if I replicate it? If you take an example with a table that has been replicated, so is my id gonna be the same in each cluster node?

Then you have availability. What happens if for example my server goes down while I’m still reading or writing something? Do I lose some data in case of failure?

Lastly, partition-tolerance; can I spread my data on another node? So, if I take again the example of a shard, can I put data ranging from A to B on the server and data ranging from C to something else on another server? So, can I spread my data across different nodes?

And if we take the CAP theorem and we look at relational database management systems or NoSQL, both have only part of the solution.

If we talk about relational database systems, you have consistency. That’s for sure because we have the ACID properties. We have availability because you can still create a cluster with high availability but you don’t have the partition tolerance.

Another problem is if you look at NoSQL databases, you kind of missing consistency but you do have availability and partition tolerance. So, there’s no ideal solution; each one has its advantage.

Now that we’ve seen that, let me give you a couple of good use case and bad use cases when using NoSQL database. I hope this will bring a bit more light into what I’ve been talking about.

First, we’re gonna explore the semi-structured data aspect. A good example of a use case for NoSQL database would be to model a mechanical part catalog. Basically, you can decompose complex object like for example a plane into smaller pieces using the hierarchy called data structure like NoSQL can propose.

Another thing is for example, handling threaded discussions. Because a discussion thread can be forked into several discussions with replies, with comments so that’s a typical structure that relational databases would struggle to model and these are really good use case for NoSQL databases.

Another interesting topic and interesting use case for NoSQL database is anything that is related to big data. Relational database systems are very comfy to scale at some form. When you increase the volume of data and you still want decent performance, you’re gonna reach some bottlenecks but with NoSQL, you can really play well with big data and this is gonna be more and more of the subject because of the arrival of IoT (the Internet of Things).

The internet of things is actually generating tons and tons of data because there are sensors everywhere, there’s information going on around with your environment that has been generated with this connected object. So, all of these is gonna feed some big data into some NoSQL database and this is a pretty good example.

Another example is science project. Science project generally deals with lots and lots of data. So, these are use cases that NoSQL databases can address pretty well.

Another kind of example is real time data.

In relational databases, there is always a check for ACID properties; it takes a bit of time to read and write data. But in NoSQL, you don’t have this so basically, you can run item, read data pretty fast and this is critical for social networks. For example, twitter. When you tweet something, you want your tweet to be available to everyone instantly. If you try to do that or if they try to do that using the relational database system, they could never achieve such speed.

Another sector in which real time data is critical is in stock exchange. Stock exchange is something that is really updated every second; that’s really intense read and write operations for stock exchange. So, these sums up a couple of good use cases for NoSQL.

Now, let’s have a look into when NoSQL is not such a good fit. I have listed at least two main topics here. First topic is with critical data. Again with the lack of transaction, you can lose some data or you can miss some updates. So, this is really not a good fit if you handle critical data especially when you deal with money. Money transfers cannot be modeled with NoSQL DB. It’s too dangerous, you risk losing transactions and that’s pretty hard.

Next thing also that is really difficult but still possible, it depends really on the database used is to create complex relationships and ad-hoc queries. Ad-hoc in the sense that you’re gonna write in real-time queries that you haven’t thought of when you implemented the schema so dynamic queries. And this is really the case when you do some dynamic reporting. When you want multiple tables and you want queries that draw from multiple tables dynamically; when you explore some data and try to create dynamic relationships between multiple tables. So in most of the NoSQL databases, this is not generally very good in terms of performance but there’s still some counter examples with that with graph databases but I’m not gonna go further on this topic.

We’re gonna jump now to the point where we have to start and talk about Bonita. So, I’m gonna present you something a bit more practical and I’m gonna talk about our work here of combining, integrating MongoDB and Bonita. So first of all, let’s ask ourselves “What can be done?”

So what I’m gonna be doing, I’m gonna be presenting to you live in a couple of minutes the integration of MongoDB with Bonita using Bonita connectors. I have done those Bonita connectors and I have taken them to store some business data; this is gonna be used by my process. Just a disclaimer here because some of you might already wonder this: Bonita engine does not and will not in any new features support MongoDB. That’s something people have already asked in the past and there is no plan, it’s actually not possible up until now because MongoDB does not provide transactions and our execution engine is actually really heavily dependent on transactions. So, we’re gonna focus just on connectors for now.

How does this work? Basically, we have two options. We can connect with two methods. We can have it work with direct connections or with something called a datasource.

I’m gonna present both solution and I’m gonna explain a bit what are the pros and the cons of each solution.

Starting with option number 1 – direct connection. The first advantage using direct connection is that actually you don’t have to configure anything on your application server. All the configuration is actually contained in the connector and in the process. That’s something you can pretty easily deploy. The drawback of that however is that you’re duplicating your configurations. For each connector you create, you have to store again username, password, host, etc. So in the end, it’s something that is very difficult to maintain. Another drawback of direct connections is that they have pretty low performance because they don’t benefit from connection pooling.

What is actually happening when using direct connection is that each time you request some data, your connector is gonna have to establish a connection with the remote MongoDB server. If there is authentication, you need to send information about authentication. There’s a network traffic back and forth and you’re losing time so this is why we’re gonna recommend option number 2 using datasource.

When you use datasource, a small drawback is that you have to do some configuration on the application server side. So, before actually using it, you need to set it up on your application server but once it’s done, it’s a configuration that you can share between all your connectors and all your processe. It’s not something that you have to redo again and again. So in the end, it turns out to be a maintenance advantage to have your configurations stored on your server rather than in the process. Most importantly, when you use datasources, you benefit from connection pooling. Because the datasource is keeping a pool of connection, when you want to use your connector, you just grab an open connection. You don’t have to re-establish a connection; the connection is already available for you to use.

So again, I really wanna recommend option number 2. To show you a bit how this works, here are some screenshots of the different connectors we’ve been implementing. Again if you use on the left, direct connection, you have to share all the connections settings; that’s host, port, database, username and password plus the command. Actually, I have added this to the screenshot because it’s actually on another page. You have to share all of these settings and to repeat them for each connector. So that’s not really convenient.

Now on the other end if you use the datasource connector, you just have to know the datasource name and the command you want to run. These are the two settings you need to provide. So these are the only two settings you’ll be duplicating in the end. So, it’s much easier to maintain and also there’s a much better security here because you don’t have to re-enter the password each time. So that’s something to consider.

Now, we’re gonna focus more on this datasource connector. Let me give you a bit more background on how it works.

The datasource connector is gonna be sitting in your process. Your process is gonna be deployed on the Bonita execution engine. This is of course inside your Java server. Java server, this would be tomcat for example or JBoss or whatever. When you need access in your process to Mongo data, you call the datasource connector. Datasource connector will call a JNDI resource. JNDI stands for Java Naming and Directory Interface; it’s part of the Java standard. In this source you have a set of JNDI resources identified by unique names so this is the property actually that you’re calling with your connector. This datasource is actually a class on your server that is actually connected to your MongoDB. So, it’s holding the connection pool and returning back your connector and if valid connection on which you can run your query back and forth to MongoDB. So, that’s the architecture that we’re putting in place and I’m gonna show you that now live.

I’m gonna switch to Bonita. You can see I have my Bonita BPM studio running. I have two processes running. The example I have chosen to share with you is actually an example in which I’m managing a product database.

So, I have two processes in place. I have a process in which I can add a new product and I have a second process in which I can list and then edit my product. As you can see in the different task, we have connectors. These are all using my Mongo datasource connector. Now on my application server, what I have deployed is actually a Mongo datasource. So, I’m gonna show you just the configuration of this. I have a Mongo server running in my computer and let me just show you what I have done to configure it; show you how simple it is to deploy.

I’m in my studio, looking at my tomcat, looking at my configuration and my Bonita configuration, I have the Bonita engine database here listed.

And I have another one called mongoDS. That’s my Mongo datasource that I need to configure on my server. Here, you have the name “mongoDS”.

Then, you have a couple of properties that are standard for this type of object. I have my configuration settings. My database is working on my localhost with the standard port, my database name is “test”, I’m not using any password or username and I have a pool of connections ready for me. It’s gonna open a minimum of 10 connections and it can grow up to 100 connections when I request for connection.

Next in my Bonita process, I have these connectors. These connectors, if I open their configuration, they are all calling this Mongo datasource. This mongo datasource that’s the one defined in my property and they are performing Mongo commands. This one is just listing all my product types and rendering them as an array.

Let’s see that in practice. If I click run in my process, it’s gonna deploy it on my tomcat and I’ll be looking at it pretty soon. Don’t focus too much on the user interface; I have done it very quickly. So, the user interface is not the main focus here.

Here I have my list of products. They are ordered by label but there are different product types; you have a mix of books, audio albums and movies. So here, I’m really exploring the fact that I can have different object structures in my database.

So, if I take for example the audio album called “Homework”. I can edit it and I’ll be able to see a detailed view of this object. So, you have instead of standard properties and then you have some extra properties which are part of the flexible schema.

Here, notice that we have a track property. Track property is actually an array and in this array I have more than one value.

If I want to do the same thing with a relational database, I would have to have lots of different tables to link them in RDBMS. Here, it’s just one document that you’re looking at right now and I can mix different types of documents.

Back to my topic, I’m just gonna create a new product.

So that you can see I have to specify a common header and then I can specify some other things, like for example I’m gonna add another book to my list. I’m gonna give it a number. I’m gonna take a famous book that you might heard of and I’m just gonna copy some description and I’m gonna give you the price like $10. Sending that.

So, this is actually writing to my database and then I can write some properties.

Here, I have some basic properties and I can extend my schema if I wanted to add some information. Let me just fill in the basic data. So, the author is “George Orwell”. I’m gonna remove the ISBN. I’m gonna add one more property like rating for example. My other documents don’t have the rating but this one, I may as well have a rating and I’m gonna rate it 4. And I’m gonna create it.

Now, if I browse back at my list of products, I’m gonna see it in my list of products.

And it’s here at the top of the list. I have my new book.

And with the specific properties that were not present in the other documents. It’s showing the power of the semi-structured data. I can write new attributes as I want, I can really create complex stuff here that I could not achieve with a standard relational database system.

Everything that I have shown here, the process example, the connectors, I’m gonna contribute that to the community. It’s not done yet but it will come soon after the webinar and you can get a chance to play with those.

Back to the slides, I’m gonna conclude this presentation. What we have seen during this webinar is we have seen the power but also the limitations of choosing NoSQL database. So, we have compared them with traditional relational databases and we have also seen a practical example of how to integrate MongoDB with Bonita BPM. So, even if I was a bit pessimistic about the future of NoSQL databases saying that there are too many players on this market, it’s still growing in popularity as well as in maturity.

As a side note, there’s actually some project to extend NoSQL databases by creating a new generation of database called NewSQL.

NewSQL is something that is really really new. It’s coming from the last years. It’s the idea to create the same databases as NoSQL but with transactional capabilities. So, this is something you really want to listen to. Well, it’s still too young to talk about yet but it’s something worth considering.

Anyway, I hope I have shown you the power of NoSQL databases and I hope next time you implement a Bonita BPM project that you may consider this option for storing your business data.

Thank you all for following. Again, the resources are not yet shared on the Bonita community but you can still grasp the connectors and the MongoDB datasource from my GitHub account. The video of the webinar will be shared and I will also publish all of these resources with the process and the examples on the Bonita community.

Common Questions

Some people are asking actually for some code and see some examples about the practical implementation of the Mongo connections. So, there are 2 things you can look at. I’m not gonna comment the Java code of the connectors. You can look at them on GitHub. If you wanna look at some practical examples of queries using fetching data and reading it, let’s just take an example. For example, if I edit a product, I can look at this connection to load a product.

So how is it done? We have again the parameter to connect to MongoDB database

And you have a second parameter here using groovy script that creates the query to load a product. So how is this working? I’m gonna detail a bit its code. Here you see in the expression editor the query to retrieve a product.

So, we’re connecting to our database. We’re connecting to the product connection and we’re performing a find operation. The find operation is working on a specific id object with a value of productId. productId is actually one of my process variables and it’s the product that I have selected from the task called select product and it’s returning the object as an array. So this here writes a simple query to find an object with an id.

If I take another example, when I update my object with another query, I write down the product of the query. This is done with a bit more complex query.

I’m still connecting to the product collection. This time, I’m calling an update method.

I’m specifying how to search for the object I want to update so it’s the same thing as the find method. I’m looking at my object with my id and then I’m writing on the update operation.

Update operation is using a set operation. Here, I’m updating the different properties of my object header.

So, as you can see writing down a couple of queries is really simple. This is why I haven’t shown too much code. It’s really simple. It’s really text based and the language is much much easier to understand and easier to learn than just regular SQL; the less operations you can perform.

What is the actual reason why we cannot handle finance data?

This is because of lack of transactions. If you have an error in your queries, you will have a partly updated data because you don’t have any transaction. If you are using a transaction and you had an error on your query, you would roll back to the initial state so before you were trying to attempt your operation you will not be stuck in the middle of your operation and you would not leave incoherent data in your database.

Do you have a customer who has implemented large scale MongoDB store in conjunction with Bonita?

Yes, we do but unfortunately it’s not someone I can talk about. One of the other use cases that I can talk about with the NoSQL DB, it’s another customer. It’s a states customer that has actually used elastic search. Elastic search is not exactly a NoSQL DB but it’s working with a NoSQL DB. It’s a search engine. So, this is kind of a good use case to use a NoSQL databases to store index information for your business process so you can do a search engine to find out process instances or specific objects that the process are working with.

Can you support the JavaScript in scripting to directly manipulate JSON, BSON data in Mongo?

Yup. Actually, the queries that we’re writing as you can see in the screen, it’s JavaScript. Here, db.products.update part is actually JavaScript.

I have another example that I can show you, when I’m creating a new product type, I’m actually using another collection.

And when I’m pushing this code here to the server, I’m pushing an entire JavaScript function. With this block of code, what I’m doing is I’m generating a new id on database server side. I’m inserting my new product type with this generated id and the name that I have taken from the form and I’m returning the id.

Notice here that I can write an entire JavaScript function that I can push on the MongoDB side. It’s not Bonita that executed this JavaScript function; it’s really MongoDB and MongoDB returns me the id that has generated. So the answer is yes, you can write some JavaScript that can be pushed to manipulate JSON or BSON.

How good MongoDB is with geospatial data queries?

There are some specific types that are implemented in MongoDB to deal with geospatial data. I haven’t played with them myself but if you read the documentation there are some really detailed examples. So, I believe MongoDB is quite good with that.

Can you configure your connector to add and delete properties during edit or just creation?

Actually, you can do everything you want. When I edited my product, I used a property called set. If we look back here, I use a property called set here when I did my update. The set is to assign attribute. Don’t look at the slash here, it’s just to escape the special dollar character but if you write it down in charset it will be set. Set is to set a property value. If you use another attribute in conjunction within this operation, you can unset attribute. So, you can delete and create new attribute just like that. You can do both.

Is MongoDB used only for the business data?

In my example, yes. It is only used for business data. Remember that you cannot use MongoDB or NoSQL databases for the Bonita execution engine. However, you can still use it if you want to create a search engine to look at your process but you will need to duplicate data within a NoSQL database.

How good is MongoDB with analytics?

MongoDB is okay with analytics but that’s not the perfect fit. When you deal with analytics, there are basically two ways to approach that. Either you have prepared a specific structure in which you have prepared your data to be read and the state of the report or you have to query your data and to look at different collections and doing some JOINs between them. And this last option, doing some JOINs between multiple collections, that’s not really something good for MongoDB. If you want to do JOINs between complex collections, you’ll have to use something, another type of NoSQL database such as a graph database. Graph database are pretty good at that. JOIN relation between different collections.