Sébastien Colladon is a Technical Architect for Salesforce over in France. In this episode, Sébastien and I discussed one of his recent projects; a series of templates for Postman, a popular tool for working with API’s.  The templates cover a variety of use cases for Salesforce. The project is open-source and available online through Github. We also talked in-depth about what he is doing to make integration and testing more accessible for developers. 

Show Highlights:

  • Sébastien describes the Salesforce Postman Collection.
  • We explore some of the many useful features of Postman.
  • Why a Salesforce developer might use Postman over something like Workbench.
  • There are just under 200 templates in Postman, Sébastien provides some examples, like the REST API, and how they can be used.  
  • The challenges and triumphs of building the Postman Collection. 

Links:

Shoutouts:

Philippe Ozil

Episode Transcript

00:07

Sébastien: Today as architects, my main goal is to ensure that we’re going to deliver the future the customer wants successfully in this platform, it is going to be integrated.

00:18

That is Sébastien Colladon, a technical architect for Salesforce over in France. I’m Josh Birk, Developer Evangelist for Salesforce. And here on the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today, we sit down and talk with Sébastien about a very specific project that he’s been working on, which is a series of templates for Postman. All of this work is going to make integration and testing much easier for you. But let’s start at the beginning. What exactly is Postman?

00:46

Sébastien: Postman? Postman is a tool that we’ll use to simulate or to play HTTP call, so you’re eligible web services with it. You can configure the web service and you can have the result of that execution of these websites. And this is basically what it does. But it comes with a lot of handy feature like for example, or advanced machine cogeneration and collection organization of your core your built folders kind of very handy for collaboration, walking and designing of integration.

01:23

If I’m working with Salesforce, why would I use something like postman over something like workbench,

01:28

Sébastien: if you want to use Postman instead of Workbench, this is basically just to be able to store the design of show integration, for example, or if you ask to provide a way to go to a web service for an external application, you’re going to be able to build it in Postman and test it and then you’re going to be able to share it and come back to it easily because it is stored in a collection. Plus you will be able to quickly switch to another, which is not very positive very easily with workbench you are connected to another man. If you want to go to another you need to connect to the environment also and to rebuild the call you are using the previous one. And now if your workbench and postman is that person allows you to call authentication and once which is not the case with workbench because when you are in workbench you are already authenticated into your targeting. And so that kind of goes right into what your your project is really about your project is like a collection of templates. Can you kind of describe what’s in your repo? So what’s in the repo is basically a collection with a lot of API calls. There are structure API. So we have that on occasion. We have API v1, bulk API v2, the REST API, the metadata API, the tooling API, and it comes also with a preset folder headers you need, because depending on the API you are going to call, some errors are present or not. And it comes also with a boilerplate for the environments you need. This way, if you duplicate the environment, wherever to configure it to target and also sandboxes, and you will be able to switch between around Verizon.

03:22

Josh: And how many templates do you have in there right now?

03:24

Sébastien: something like just under 200

03:34

Josh: So that’s a that’s a lot of different templates. What are some examples of specific ones that are in there?

03:42

Sébastien: For example, we are for the REST API, there is a lot because there is a lot of describing can do or a subject relationship. You can you can go through, but basically, this new structure, type of API, so we have metadata rest tooling. API, v1, v2, tighter API composite API for that kind of stuff.

04:06

Josh: Nice. And so give me an example of how you would use one of these requests, you know, a template of these requests like in your day to day life.

04:16

Sébastien: So why can one what I will try to explain to you is another use case than the one that is in the in the past. And it is a more recent one. Also, like recently, I needed to choose the API v1, one of my customers do. And in order to do API v1 he has is a very complex orchestration. It means it’s going to load different kinds of objects, and with different kind of pace configuration, and the goal was to tune it very well. So all the cores are not shown the same way. And in order to be able to gather data around how the API behave, with This kind of data, this kind of custom object, we needed to split the work in a team. So what I did, I just created a workspace in postman, put it the API calls we needed for the API. And we just created the work. Everyone duplicate the collection, and just configure the API to call the job the objective was to, and then we gather the result with the same template. And we will be able to choose we have been able to choose who we want for this customer very, very fast and very, very easily and corroborate it.

05:36

Josh: Nice. Nice. So it’s interesting that the collaboration angle on that, like, you can take a little bit of information and a lot of people can replicate the same kind of integration that you’re doing. Is that is that an accurate description?

05:50

Sébastien: Yeah, actually, when once you have done the import, you can export it, then you can share it, and then everyone is able to replay it in this video. You all know one, but you can repeat the exact as you have configured.

06:03

Josh: And you can also handle authentication across different kinds of work. So you can handle that integration, whether it’s in a sandbox or a scratch. org or production.

06:12

Sébastien: Yeah, exactly. You can target a sandbox that’s crunch on production environments. You can target trailing pregnant if you want. You so you can forget anything.

That is awesome sauce, guys. And this is all open source and online, correct?

06:28

Sébastien: Yeah, correct. This is posted by GitHub. And this is open.

06:32

Josh: Well, and I think this is an interesting use case of open source because it’s not just about you know, getting bug fixes and, and features into a project. This is also about expanding the collection for different kinds of templates, right?

06:46

Sébastien:Yes, right.

06:48

Or of the current template, well not present. I think I started with API but we’ve already been through improved the debate, and I hope this templates will be improved more and more with the the community growing.

07:05

Josh: Were there any particular challenges that you ran into when you started putting this together? Or would this postman’s just kind of make this pretty boilerplate?

07:14

Sébastien: Yes, I think we should if we have encountered the same challenge that you face everywhere, this is the our your name, your variance. And yeah, this is this is very funny. But this is, in fact, a very complicated problems for software engineer. And I think everyone knows that. We actually have done I think, like, two or three meetings talking about that, just to be sure. To our to, to name all viable.

07:48

Josh: So walk me through that what was what were some variable names that didn’t make it in and then what did you end up actually using?

07:55

Sébastien: Well, first thing we need to notify different kinds of types of variables. And then we decided to put some naming convention about all those type of variables, then we try to follow some general guidance about this type. This is how I’m thinking. Again, the result is that we have three type of variables, we have user variables that are that are set by the user. And those use those variables for case changes. case, we are also the system variables, those system loggers are set by the system. When you are done. Of course, when you are set when recording a notification, notification is going to gather the access token and set it for you. So when you’re going to call a larger template, the access token will be put into it for you and the call will go smoothly without authenticating first, because it has been done before. So those kinds of information is stored into the system over time and viable. When those variables follow characters, starting with an underscore convention, this is close to the private variable in JavaScript, you have what we call placeholder. placeholder are some variables that are not included environment templates, there are into directly into the inputs. And this is where you’re going to change the value of this boilerplate that is on point, if you want to ask the API to give you a describer for object, we’re not going to duplicate all this code for every object, because it will be huge. And in fact, it will be also incomplete because any customer can create custom objects, which I can’t know before. I can go in that right.

09:49

Josh: And that’s our show. I want to thank Sebastien for his hard work on this project. And I hope you’ve enjoyed this short introduction into his efforts. Now of course in the show notes, we will be linking to that project. As well as a blog post that was co authored with PhilippeOzil on how to get started with it. Thanks for listening everybody. If you want to learn more about this podcast, head on over to developer.salesforce.com/podcast where you can hear old episodes, see the show notes and have links to your favorite podcast service. I’ll talk to you next week.

 Get notified of new episodes with the new Salesforce Developers Slack app.