MuleSoft Workshop

After our Field Service Lightning Workshop we had another one – this time about MuleSoft.

This time we had about 30 attendees even from non-Salesforce companies, we had Rob Roop for a short introduction and the only MuleSoft Ambassador in Europe – Patryk Bandurski.

MuleSoft Workshop Attendees

MuleSoft and Salesforce

Sadly the MuleSoft team from Salesforce was fully booked for other events, but Rob did a great job presenting something he really didn’t know much.

He spoke about importance of integrations, how companies are getting more and more connected, but there was one slide which I liked the most – the different types of integrations on Salesforce platform.

Rob Roop presenting MuleSoft

MuleSoft when you need to orchestrate multiple APIs, Salesforce Connect when you want to reference the external data but don’t really want them in Salesforce, Heroku Connect because it might be easier to connect to Postgres, Platform Events when you want something in real time, Salesforce Customer 360 when you need to connect customer data from different systems and consolidate them or Salesforce API when you know best what you need.

The MuleSoft

And with that we passed the word to Patryk, who orchestrated the rest of the day. He split it into 3 parts – Application Networks, API lifecycle and Prototyping.

Application Networks was to me mostly introduction to the integration world. System APIs, Process APIs, Experience APIs and finally the Application Network, when you don’t have to connect systems point to point but they can communicate through network and don’t really know how to talk to each other. ESB in IBM world, nothing new to me.

But it is important to see the future, because with first integration you might be tempted to make it point to point, but that will block you in the future.

Anypoint Platform, which you can use to design the whole experience. And that’s the point where I occasionaly lost myself and had to find me again. Switching back and forth, different types of artefacts – at the end it wasn’t that hard, I just didn’t see the picture at the beginning.

We started at Sign-Up page, where anyone can start 30 days demo. MuleSoft Kernal (aka Community Edition) was thrown away (or I feel), you can download something and much more, which is usually too much to me, when you can survive with the web.

The whole process is pretty easy after all – you design, simulate, gather feedback and validate. As with everything else.

API design phases

Anypoint Exchange has a tons of artifacts you can use – examples of connections to popular REST API, description of common data structure and much more. All of it can be linked and used in your API, with versioning.


MuleSoft uses RAML (RESTful API Modelling Language), which has pretty readable structure and the editor isn’t bad at all. Might be hard to remember all the defaults, so you can skip thing and know when you shouldn’t do it, but after all it shouldn’t be that hard to learn it. After all there is a certification which you might want to get – API Design Associate.

Fragments after fragments, linked together and at the end we had the data structure for the call. Somehow is looked odd, to write it by hand, when we have Swagger or Apiary and we should be able to reuse the documentation someone else already did, but whatever, it is probably possible to use them somehow.


I got lost again for a while, but found myself quickly. Mock service is something I know from Salesforce as well, so we designed the API and tested it. Or are we already in the Feedback phase? Lost again 🙁

API designer

Never mind, the designer is nice, we somehow had to enter the structure of the data again and then save as a new „type“. More and more typing, frankly, it scares me.

Feedback and Validate

Yeah, I got it. Not sure where in the spiral we are, but I understand, why it is important. I like the fact that you can comment on the Exchange, something maybe Keboola can invent 🙂 Or rather not, that would mean I have to reply to customers who uses my free Salesforce Extractor/Writer.


Design Center

Now the fun begins. We have all those artifacts, API definitions (or is it the same) and we put it together into one big flow, which can have several (a lot of) steps and do crazy things. Obviously it can reuse information from previous steps, do some logic, iterate through variables, handle transformations. Pretty cool, you just need the imagination.

The deployment was pretty longer than I expected, but in real life it should run the old version till you deploy the new version, so there shouldn’t be any downtime. Nice.

MuleSoft Catalyst

The last topic – Catalyst, which should enable organisations to learn quicker. Accelerator for three large projects full of best practices and ready to go pieces.

Which somehow go together with MuleSoft.U courses, which are for free and you can take them any time you want. They are on my to-do list for a few months already, hope to finally get to them. You can also find some modules on Trailhead and I feel there will be more.


Would you want the presentations we saw during the day, here you go:

Leave a Reply