Camunda Community Podcast

Inbound and Outbound Connectors: "Woah, it's so easy!"

• Camunda Community Podcast • Season 5 • Episode 1

Share episode

Connectors are reusable building blocks that can communicate with any system or technology, providing unlimited flexibility and reducing the time it takes to automate and orchestrate business processes. Ever since we introduced Connectors with Camunda Platform 8, excitement has been growing and we’ve added more and more of them to meet the ever-increasing number of use cases. 

In this episode, Senior Technical Community Builder Mia Moore chats with Bastian Korber, senior product manager for Connectors and the Integration Framework, about Outbound and Inbound Connectors, their architectures, example use cases, and what’s next. Listen to learn about the main differences between the two, how Connectors can be deployed to build better processes and save you time, and why Bastian calls Inbound Connectors a “game-changer.”

Share your questions or feedback about this episode on our forum.
Start your free trial of Camunda Platform 8.
Save your seat for CamundaCon 2023. 


Additional Resources: 



---

Visit our website.
Connect with us on LinkedIn, Facebook, Mastodon, Threads, and Bluesky.
Check out our videos on YouTube.
Tweet with us.

---

Camunda enables organizations to orchestrate processes across people, systems, and devices to continuously overcome complexity and increase efficiency. A common visual language enables seamless collaboration between business and IT teams to design, automate, and improve end-to-end processes with the required speed, scale, and resilience to remain competitive. Hundreds of enterprises such as Atlassian, ING, and Vodafone orchestrate business-critical processes with Camunda to accelerate digital transformation.

---

Camunda presents this podcast for informational and entertainment purposes only and does not wish or intend to provide any legal, technical, or any other advice or services to the listeners of this podcast. Please see here for the full disclaimer.

[NIALL DEEHAN] Hello! I’m Niall and welcome to the Camunda Community Podcast where you’ll learn all sorts of things about Camunda, BPMN, DMN, and general orchestration topics. Today, we’re going to take on a topic that is kind of close to the heart of the community because a lot of people are getting involved and asking about Connectors. Connectors are a new feature in Camunda 8 that have existed for the last maybe eight or nine months, and are kind of a big component in how people connect to existing systems. The best people I think to talk about this, of course, would be the product manager for the Connectors project which is Bastian Korber, and, of course, my own colleague–the Senior Technical Community Builder Mia Moore. They sat together to discuss all the things you want to know about Connectors to help you understand what they are, what they do, and how to use them. So, let’s get started. 

[MIA MOORE] Today's episode, we're talking about Inbound Connectors and Webhook Connectors, and I have with me Bastian Körber, senior product manager at Camunda. Welcome!

[BASTIAN KÖRBER] Hi. I'm a senior product manager at Camunda. I’m responsible in general for the Connectors and everything around this so like their whole ecosystem for Connectors. I joined Camunda in December so it’s actually my 6 months, I think. Since then, I took over the Connectors. 

[MIA] Yeah, I didn't realize you joined so recently. So what exactly, if I didn't know anything about a Connector, or what connectors are, what would you describe them as?

[BASTIAN] Connectors are really about connecting systems. And this means, Camunda to any third-party system, or any third-party system to Camunda. And that's the easiest explanation, I would say.

[MIA] Yeah, yeah! So let's talk a little bit about Inbound Connectors first, and then we'll move into Webhook connectors. So what do you define as an Inbound Connector?

[BASTIAN] So Inbound Connectors, really that we are enabling external systems to trigger Camunda. So with Outbound Connectors, we were always triggering external systems. And with Inbound Connectors we are actually opening up the gate for external systems. And so we are enabling external systems to trigger us, and that we are creating a new process instance called by a third-party system. 

So, for example, Twilio–Twilio is a messaging system–and we want to start a process when we are receiving SMS, for example. Right now there was no solution. And now you can spin up an Inbound Web Connector and every time, if we are receiving an SMS, we start a new process and can work with this SMS and can answer this. For example, the customer request–we can directly get the SMS can answer it, and so on. So this is the difference: Outbound Connector was always triggering something, so we triggered the system; and Inbound Connector, really easily spoken, is we get triggered by an external system.

[MIA] Yeah, that sounds really useful, because I'm trying to think if there would even be a way to do it where, like any workaround–I guess maybe if we triggered the SMS message from Twilio we could do it that way. It's sort of the opposite way, but there was nothing previously like this. Right?

[BASTIAN] Yeah. It was always complicated. But so you had to do some customizing stuff like calling a system or integrating your own solution. But there was no out-of-the-box solution. So every time, if you wanted to get trigger, first, you could use our GRPC bridge, which GRPC is not a really known protocol. So some customers created the REST Connector Interface between this to start a new process. But from the Modeler itself, there was no easy solution to really enable this. Now, with the new Inbound Connectors, you're just writing a new start event, saying, for example, “This is a Webhook connector. This should be the URL. This is what I’m expecting, this the authentication.” You're deploying the process, and then you're going. So super super easy for really complex topic, which normally takes a lot of time to develop.

[MIA] Yeah! That sounds like a way easier alternative than kind of your own custom solution for insert thing here. Do you want to dive into a little bit how they work, and what the architecture is, and that sort of thing for our more technical audience? 

[BASTIAN]  Yeah, sure. So maybe I'll start with the difference from Outbound to Inbound Connector. So Outbound Connectors were really stateless, so it was just fire and forget. We trigger the system, get the response, and then we are done. Inbound Connector is different, because Inbound Connectors has to start a new process. So they're actually listening to every process which is deployed and checking, “Hey, is there any Inbound Connector?” And if there's an Inbound Connector, we adjust some things and listen to an event. And this is a totally different architecture than the Outbound. It's really stateful. And this was also really complex to develop. Because before, Connectors were just stateless, and now we are stateful. So we are actually spinnng up a Connector for Runtime which is first listening to Operate and asking, “Is there any process which needs, for example, a Webhook start event?” And, if so, we are listening to the service which is configured. 

And, for example, let’s go back to the Twilio example. We are listening to Twilio and saying, “Okay, if we ever receive an SMS, I have to start the following process instance.” And this is totally new. This is like the new architecture. And maybe I can just guide you through the lifetime of this Connector. So, first of all, we are starting the Runtime. So we are really spinning up the Connector’s runtime, the Inbound Connector. Then we are configuring the Connector in the Web Modeler. For example, you are dragging in the start events, saying, “Okay, this is my Webhook URL, this is the authentication.” Then I’m deploying the process. So this means the webhook is now active. And now, I have to get the URL and go to the third-party system which actually should call us. And, if you’re staying with Twilio, so we are going to Twilio, saying, “Okay, if you receive an SMS at the following telephone number, just call the Camunda service.” So we’re actually spinning up similar like an API endpoint for Camunda which can call us and, every time they’re calling us, we are starting a new process instance which is executing the process. 

That is like the difference between Inbound Connector and the Outbound Connector. Outbound Connector was really just, we had a trigger like a manual trigger or anything was like a time-based trigger, and then it was a specific time where we were just executing a Connector. But now, with the new start events and Inbound Connectors, we are actually spinning up a process. So we are not directly part of the process, but we are creating new process instance, right? And I think that’s the biggest difference. 

[MIA] Yeah, even just you describing it. You said it took a long time to develop and was complicated to develop, and that makes total sense, just hearing how you described it, and how folks would have to have done it before if they wanted something similar. So yeah, that sounds like it's much easier for the user because they don't have to do all of that messy stuff. 

[BASTIAN] Yeah, absolutely. For me, this was really as I saw this for the first time, I was like, “Woah! It's so easy.” I didn't expect it honestly, just bring the start event to the Web Modeler and  configuring it, and then you have an endpoint. Because in the past it was super complex, and I think this is a big game-changer for a lot of people who want to call Camunda not just calling in a system from Camunda. So it really the other way around. 

[MIA] Yeah, totally. Do you know of any use cases or specific examples that you could share where people are using this effectively?

[BASTIAN] Yeah. So what we have actually is in CI implementation. So where we’re using the GitHub Webhook integration. So every time, if something is changing in GitHub–so, for example, you're creating pull request–we can spin up a process, and then you can, for example, just imagine you're creating a pull request and want to have to review and like an approval workflow. And we are just listening to this event, starting a new process. And then we are saying, “Person X has to approve this, and then the next one has to approve as well,” so we can cover the full approval process from the GitHub implementation. So this I think is a really good case. 

[BASTIAN] Second case is customer services. So every time, if you're getting a new message and so on, you want to spin up a process right? So you want to respond, maybe you need to check something beforehand, and there we can just directly catch the message. Maybe check data in Salesforce. Is it actually a customer? What kind of issues did they have before, and can I solve this automatically? Or do I have to escalate this to a human, and then we can create a human task and can really start our process. So there are a bunch of use cases here. Every time, if we want to listen to an event, especially with a Webhook, it's also like, for example, if you're creating a new order in Salesforce, we can listen to this webhook and spin up a separate process around that.

[MIA] Yeah, it just sounds like it expands the possibilities immensely. I mean, it's one of those things that before you have it you're like, ohmaybe you don't envision it, you can't think of it. But then, once you have it, “You're like. How did I live without this?”

[BASTIAN]  Yeah, absolutely. Normally, we were overthinking from the top level and we were orchestrating everything. But now we're able to hook into systems and we're listening to events and then spin up a new process. So that's really cool and super super easy. And, like, as I mentioned, this super easy configuration is really game-changing.

[MIA] Okay. So we talked about Inbound Connectors and Outbound Connectors, and you mentioned web hooks a little bit, but we also have Webhook connectors. So what,  what is the difference there?

[BASTIAN] Webhook is a specific type of Inbound Connector. So we actually we have in the future 3 types of Inbound Connectors. And we started with Webbook. Webhook is based on the REST protocol. So we actually spinning up REST endpoint, which is currently supporting Post messages. And you can call this endpoint via every REST client, or like, if you have Postman installed, you can call it. Why is it called Webhook, and not REST endpoint? I think a lot of people ask me this. Webhook is just a specific term that you're triggering a process. So we are just doing. And then we are saying with webhook, “Just trigger us and don't provide any big data, and so on.” So it’s just more triggering. I think that's the biggest difference between Webhook and the REST endpoint. But anyhow, the technology behind this is really we're spinning up a REST endpoint which supports Post, gets a body message, and you can do whatever you want with it. Yeah, that's the difference. So Inbound Connector: Webhook is one type of an Inbound Connector. 

[MIA] The next question on my list is: What’s happening in the future? So let’s dive right into it. Tell me everything. 

[BASTIAN] Yeah, perfect. So, currently let let's stick to the Inbound Connectors. So currently we just talk about start events. In the close future, so in one month or I’m pretty sure in 8.3, we will support intermediate events as well. So it's not just that you can start a process, but also, in the middle of a process, you can define an Inbound Connector. So if you're just saying, okay–good example is UiPath bots. So you started UiPath bots. You had no clue when it's done. And the current solution would be you’re pulling, so you're always asking this: “Are you done? Are you done?” And maybe after one day or a few hours, you're getting the result.

[BASTIAN]  With intermediate events, you can just say, “UiPath, call me if you're done.” So, we are not pulling. We’re just saying this URL, call me if you're done, and the bot is calling and saying, “Hey, now I am done. Now, you can continue this process.” So this is also a big change like the intermediate events. And then we introduced message queues for Inbound Connectors. That's the second big thing. Currently, we're working on RabbitMQ and Kafka which really supports our microservice orchestration. So we are connecting–currently, we have RabbitMQ and Kafka producers, so we can send events, but we can't receive events. And to make the story round, we also need to support receiving or subscribing to an event. and that's what we're currently working on, so really listening to events, and then executing. which is also super powerful. 

[MIA] Yeah, yeah, I can. I can already envision sort of different things that you could do with that. That makes total sense that that's next on the list. If someone wanted to find out more about connectors, what connectors we have available, where could they go?

[BASTIAN] There are several areas. So one is for sure documentation, and you can find everything. But we also have several community contributions and partner contributions. So if you want to check it out, go to our Awesome Connectors list. So we have actually, in our GitHub, an awesome connector list where you can see several contributions from our community already, and also from our partners. But there you can also find our own out-of-the-box Connectors.

[MIA] Awesome yeah. I was hoping you would mention the Awesome List, because I help out with the Community. Hub, so that's like my baby. So I'm like, “Yes!” We have all the connectors listed there, and that's really great, because, having them all in one spot makes it easier to see, especially those partner connectors and the ones that aren't under like, maybe not in our documentation and not official Camunda and such. But also folks can make their own connectors. Right?

[BASTIAN]  So yeah, absolutely. And there. We are also now supporting inbound right? So you can create your own inbound connector. So if you want to have a system-specific connectors– I mentioned already Twilio or Salesforce–you can create it. For some, you only need to create a new template. For other ones, you can use our Connector SDK and really create your custom solution, and add your custom, logic, whatever you want. So it's not just that we are providing the out-of-the-box connectors, so we are always providing Connector SDK support. So everything that we are doing as part of our Connector SDK, and everyone can access the Connector SDK. So actually what we are doing everyone else can do as well, because we're using the same base. 

[MIA] Yeah, that's awesome. And I love that too, because, you know, if you, if you create a new connector, you can share it with the rest of the community and everyone benefits. So yeah, very cool.

[BASTIAN] Yeah. And actually, that's where we want to go. Right? So that's also how we, are seeing, envision the future of Connectors, I see, Connectors as an ecosystem, and honestly, everyone needs to connect to a system. And why should we do it twice if we can just share it? And the Awesome List is a good start where we have one spot where we can share it, but I think also in the future, having something like a marketplace where we can make it more visible, easier to discover, and also an integration to our Web Modeler, so that it's just plug-and-play and say, “Okay, there was already a Salesforce Connector. Why should I do it by my own? Let’s download it.” Or, “There’s a specific, really cool, inbound connector which reacts to a specific need, what I also need, why should I do it on my own? Let's use the community.” And I think this is super powerful, and that's why I love this Connector SDK, and that we are using our own tool and making it accessible to everyone else. Right? 

[MIA] Yeah, I think that's such a wonderful thing to do. And again like it’s so helpful because you know, I've worked for companies where we'll see a lot of requests for a specific thing, but it's not on the roadmap. And you don't have to wait for the roadmap with this, right? Like we give you the tools to do it. So I think that's that's really great. So definitely. Check that out. If that sounds like something you are interested in.

[BASTIAN] Absolutely. Yeah, yeah. And also if you're looking for specific connectors to a specific system, right? So we have this idea of protocol connectors, and if you just check out, like our UiPath or ChatGPT Connector–they are pure templates. So you don't need to have coding experience for Java. Just JSON, and configure it, and then you have an easy-to-use connect, and then you can share with the community as well. So I think, with the new Connector SDK, we are making much more easier to create a Connector. We still have the powerful Connector SDK, which is pure Java code, and you can do everything. But on top of that, we have our Protocol connectors, which can connect to any kind of protocols; like Inbound Connectors is a good example. Webhook is a protocol, and you can customize your own connector on top of that, like the Github Connector. But also for Outbound Connectors–we have REST, we have GraphQL, and so on; like the common protocols. And you can just create your own custom templates which customize it, and make it easier to use. So I think this is super powerful.

[MIA] Awesome. Yeah, is there anything else you wanted to cover that we didn't get into?

[BASTIAN] I think we covered a lot, right?

[MIA] I think so. 

[BASTIAN] I think maybe just come back to Inbound Connector vs Outbound Connector with, because that's where we started, and let’s maybe summarize it. And the biggest difference, as I mentioned, is stateful vs stateless and also how difficult it was before to spin up like listening events, so that Camunda is actually listening to a third-party system which is now much easier and enables a lot of more business cases you can automate easily right? So before it was hard– you need to pause anything on, always take care. Now, Camunda takes care of this with Inbound Connector. and you don't need to. And you can focus on really on your process automation and on the technical stuff.

[MIA] Yeah, yeah, I think that's actually a great challenge to issue to folks is, how can connectors help with what you're doing with Camunda? Because I bet they can. If you're not using Inbound Connectors, I bet there's probably at least one area that you could, and I think that'd be interesting to see.

[MIA] So yeah, I'll wrap it up there. Thank you so much for your time. I thought I understood connectors before, but I understand them way better now, and I also want to ask our audience if you have an interesting use case, an interesting thing that you've done with connectors, we would love to hear more about it. So please let us know we'd love to hear from you, and let us know if there's anything else you want us to dive deep into with connectors. Thanks again. So much for your time, Bastian, and have a good one. 

[BASTIAN] Thank you for having me. 

[NIALL] It’s really nice to hear from Mia and Bastian and especially because I have been messing around a lot with the Connectors recently – both the out-of-the-box ones and building my own – but, of course, almost all of them being outbound. The really nice thing is the inbound connectors which the first iteration already exists in the alpha version which I’m really excited about. Which means that I’m really really looking forward to being able to build a process that uses both inbound and outbound connectors to be able to send and receive Kafka messages, like Bastian mentioned. But also that means you could orchestrate your whole process with Kafka messages flowing all over the place which is pretty cool. The intermediate events are also going to kind of be a big deal. They are already available in the alpha release which I checked out recently. It’s a really fun thing to be able to add an event randomly in your process and then be able to set up a REST call to just trigger it. Right now, webhooks and intermediate events work really well. There’s actually a lot of applications for that so I’m kind of looking forward to building some examples and seeing how the community actually uses those. 

Speaking about that, if you actually want to build some connectors or get involved with the project, of course, Bastian already mentioned there’s some nice documentation. We also have the forum which is linked in the show notes and, of course, the Community Hub as well.

Before we wrap things up, I want to say a big congratulations to the Camunda Champions. A new cohort has just showed up and I want to say thank you very much for all your work that you do. These folks go around answering forum questions, they build code examples, they talk at presentations and things about Camunda, and are a great, great help for the rest of the community that these people are sharing their knowledge. So I want to say thanks very much.  I had the pleasure of meeting a whole bunch of them at the Community Summit and it was delightful–lovely folk and looking forward to seeing them again.

But when would I see them again? Well, probably September. Why? Because in September, in New York, CamundaCon is back and CamundaCon, if you don’t know, is a lovely spot where we get a bunch of Camunda experts together to talk about the things they’re learned, built, and solved with Camunda. You can check out more details on camundacon.com and save your seat there.

If you’re interested in hearing more of our lovely Camunda adventures, feel free, of course, to subscribe and I shall leave you now. I have been Niall the whole time. Bye-bye.