MongoDB Connector for Camunda 8- Part III

Welcome to the concluding part of our MongoDB blog series! In the previous segment, we honed our data retrieval skills, allowing us to uncover valuable insights from our collections in MongoDB database. In this concluding part, let's discuss the remaining operations like updating documents, deleting documents, dropping collections and even database.

Update Documents:

In the ticket booking scenario, many a times, cases may arise that the user needs to update the journey details, with reschedulable tickets support in the process. Let’s model the process.

• First, I am creating a form to facilitate the process.

• And here is my BPMN, where I will be updating the document based on the matching Phone Number.

• Okay, now, let’s start the instance, and fill the form in the Tasklist.

• And, this is the response which we have got as a part of the connector execution.

• Upon cross-verifying the record with the matching phone number in the MongoDB Compass, I am able to see the changes persisted in the DB.

• Update Operation also supports Limit operation, where only the number of documents that is given as limit is updated, when there are more number of matching documents available, or no filters are available. If filters are null, and limit is null, the operation is just ignored and all the documents present in the database is updated.

Delete Documents:

• In our case, we need not store very old trip data or need it in the long run. So, let’s say after some 6 months, we are planning to delete the data. Let’s walk through how we can do this with our MongoDB Custom Connector. Similar to the Retrieve and Update, here too we have filters and limit.
• When we give a specific condition in the filters, then only the documents that match that filter is deleted.

• For example, in this case, I have given the filter to delete when ten PickUp point is Kochi. Seems, only one document is matched and we get the response as below.

• Next, we will try giving without any filter or limit, that is, with their default value, null. If the value of these are null, then that respective operation is ignored in the context. Now, let’s deploy the process and start an instance of it.

• We are able to see the response in the Operate as below. All the 7 records that were present in the database are deleted.

Drop Collection:

• Now that, we have deleted all the bookings (documents) from the collection, and using another collection to store the present bookings, we dont need this specific collection right now to be existent in the database. So, let's delete this collection.
• Upon configuring the activity as MongoDB Connector, and selecting the operation as Drop Collection, we will be required to input the Database Name and a Collection Name.

• Once we deploy the diagram and start an instance of the process, we are able to see the response from the connector is Operate as below -

• Also, if there is only one collection present in the database, and we are deleting that collection, then the database gets deleted too.

Drop Database:

• Let’s try dropping the entire database from MongoDB. Upon configuring the activity as a MongoDB Connector, and selecting the operation as “Drop Database”, we will be required to give the Database Name to drop.

• Here, I have given the Database Name and have started the instance. We are able to see in Operate, as a response the following output.

In this series, we've travelled through the fundamental operations that our MongoDB connector offers. From creating collections and inserting data to retrieving and manipulating it, we now have a solid grasp of our connector’s capabilities.

Contact :