Is it possible to create a conversational bot, fully functional, using Natural Language Processing (NLP), in minutes? Good news, it is.
In this post we will show you how to start from the ground up, giving you everything you need to create your own basic conversational bot, using 100% free accounts and software (yes, all this power for free).
The free accounts and software shown in this post have some limitations and it is designed for you to understand and learn the basics of:
MuleSoft’s lightweight Runtime Engine can be used to expose microservices and APIs on any IoT device. In this post, I will demonstrate how users can use MuleSoft and a Python script to create a simple API that lights up an LED bulb 10 times in a loop. To get started, please refer to the requirements, video tutorial, and steps below.
Raspberry Pi 3, LED Bulbs, resistors, jumper wires, Mule server, and a breadboard.
Mule IoT LED Project
This is second in series of how to DevOps articles, and is a follow-up to the MUnit blog – HowTo(DevOps) – Leveraging MUnit For Test Automation.
A core component of the continuous integration process, that includes the previously discussed test automation framework, is the build process. As soon as the developer commits the code to version control repository, the build tool compiles the source code runs unit and integration tests and generates feedback for the developers.
Traditional integration platforms could get away with providing some command line tools to automate the build and deployment of applications built on their platform. But in the modern world, integration platforms need to encompass the critical API management & cloud components as well, so the scope of continuous integration and continuous delivery tools are no longer just limited to integration applications only.
As organizations embrace APIs for exchanging information with internal or external customers and partners, it’s critical not to sacrifice visibility or governance. That’s where API management comes in. API management policies can be layered on top of the implementation of the APIs to provide the governance, security and visibility required.
Out-of-the-box the Anypoint platform provides a full number of policies. Policies are grouped into categories of:
Welcome to this series of “HowTos” covering exceptions in MuleSoft Anypoint Platform. We will be covering many topics specifically with exceptions and exception/error handling in Mule integration flows.
The exception handling is demonstrated using a simple use-case. The example Mule project is available in exchange here.
Integration projects are complex, and exceptions are bound to happen. It is important that we have the ability to catch, categorize and handle exceptions so that we do not leave the system/application/data in an inconsistent state.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Mulesoft’s Anypoint Platform. This blog post is a follow up to our last blog “How to ETL” using Mule. In that post, we demonstrated how Anypoint Platform could be leveraged to read a large number of messages, transform/enrich these messages, and then load them into a target system/application.
We recently introduced our HowTo blog series, which is designed to present simple use-case tutorials to help you as you evaluate Anypoint Platform. The goal of this blog post is to give you a short introduction on how to implement a simple ETL (Extract, Transform, and Load) scenario using Mulesoft’s batch processing module.
MuleSoft Anypoint Runtime Manager (ARM) provides connectivity to Mule Runtime engines deployed across your organization to provide centralized management, monitoring and analytics reporting. However, most enterprise customers find it necessary for these on-premises runtimes to integrate with their existing monitoring systems such as Splunk and ELK to support a single pane of glass view across the infrastructure.
With the advent of next generation, easy to use integration toolsets, the following is becoming a very familiar scenario.
The business has a use case to move customer records from a database (DB) to Salesforce (SFDC). A system analyst in the line of business quickly creates an integration with a connector and deploys it.
A few weeks later, the customer support team comes up with another use case to display customer data on the support web portal. So, the analyst creates another integration into the DB and SFDC.