Narender Singh is a Salesforce developer over in Berlin. He is also the author of the ForcePanda blog, which acts as a source where those with commonly asked coding questions can get answers in one place. Narender is also an animal-lover and football fan.
In this episode, we talk about his experiences with the community and learning the platform, as well as his experiences with External Services. Tune in to hear this self-confessed coding addict’s expertise.
- How ForcePanda came to be.
- What External Services are and Narender’s experience with them.
- The difference between REST and SOAP APIs.
- How to generate a good schema.
- Authentication protocols and named credentials.
- How Flow plays into the use of External Services.
- Twitter: https://twitter.com/Nads_P07
- LinkedIn: https://www.linkedin.com/in/narendersingh07/
- ForcePanda: https://forcepanda.wordpress.com/
- GitHub: https://github.com/forcePanda
- Session at London DUG: https://www.youtube.com/watch?v=mX4sI9KBY20
- Session at Noida, India DUG: https://trailblazercommunitygroups.com/events/details/salesforce-noida-in-developers-group-presents-virtualgupshup-iii/
- Deepak Anand: https://twitter.com/deepak_kanand
- Steve Molis: https://twitter.com/SteveMoForce
- Jessica Murphy: https://twitter.com/jessicarmurphy
- Amnon Kruvi: https://twitter.com/KruvMan
- Sunil Sarilla: https://twitter.com/sunilsarilla
Narender: Initially, I was very intimidated by admin questions, to be honest. But as I progress through it, I became more and more comfortable with the whole community. And that’s how I got really, really involved in the community.
Josh: That is Narender Singh, a Salesforce Developer over in Berlin and author of The ForcePanda blog. My name is Josh Birk, developer evangelist at Salesforce. And here at the Salesforce Developer Podcast, you’ll hear stories and insights from developers for developers. Today, we sit down with our inner talk about his experiences with the community and learning the platform, as well specifically his experiences around external services. But to kick things off, let’s start with the event that got him rolling, featuring former interviewee Jessica Murphy.
Narender: Yes, I did have very significant moments. I can distinctly remember. First one being me attending a meetup at New Delhi. They’ll look per user group. And there was this session by Jessica Murphy. It was a virtual session by her. And in that session, she said a line that, that stuck in my head. And she said that whatever you do, make sure that you put that thing on, you know, somewhere out there, because you need to put yourself on a map in order for other people to know that you exist. And that really stuck in my head. And another encounter that I had was deeper content. He’s one of the very active members on the success community answering a lot of questions. He, to me is pretty much everything I have learned. He indirectly directly has is always been through the whole journey. And I have learnt a lot, indirectly mostly because I know I value time. I know People are busy. So but his answers the way he approached his answer. I used to look at his answers and what was his approach to solving problems? Yeah.
Josh: And like after some of these encounters, like, you know, Jessica, talking about putting yourself out there. How did you follow up with that? And do you feel like it impacted your career?
Narender: Yeah. So the immediate thing that really came to my mind is when I was answering a lot of questions, and let, let’s say, when I was when I was about to research a bit on an answer that I didn’t know about, I used to google it a lot. And I saw some questions. I eventually realized that there is no single source of information, which can somebody refer to for these type of answers, and why not just do a blog on it, and that way, people can actually refer the single link instead of posting the whole answer or even I can do the same effect. There is some repetitive or similar questions like this. And that’s how it that’s how these two things came together and transformed into the idea of blogging. And that’s how ForcePanda came into the picture. Yeah.
Josh: Awesome. Awesome. Okay, well, so let’s get a little technical and talk about your work around external services. First, what are external services?
Narender: So the external services is essentially a declarative tool, or I would say, local tool, not exactly declarative, which allows you to make call outs without writing any Apex
Josh: and call sort of call outs to like, random REST API’s
Narender: Yes. Specifically it REST because external services as of now, they do not support SOAP use case but only REST.
Josh: And what are some examples of REST API’s. Some people might want to connect to using this?
Narender: Yeah, I mean, a lot of modern API’s are rest based. So you have Salesforce API, for example, which is a rest based API. You have WordPress, you have a lot. That’s the thing of having a lot of API’s. You have Google API’s pretty much every API which you will encounter, most of them will be rest based API.
Josh: So okay, let’s let’s take that up one layer, like what’s the use case that involves both Salesforce and a REST API? that that would be something that might be meaningful to somebody?
Narender: Yeah, absolutely. So as your system grows, as if you are owning a business, you will eventually realize that you need to have multiple platforms interacting together in order to make make the business useful, or basically run the business successfully. So the you could have a payment gateway or inventory. Which is residing out of Salesforce. And then you need to have interaction between both these platforms. So in order to do that we need some kind of connectivity. And that’s where the the concept of integration and call outs come into the picture. And, again, as we discussed, there are two kinds of API’s rest and soap, which, and most of them are based on dressed in the modern era.
Josh: Gotcha. And what’s the role in creating a schema in order to get an external service up and running?
Narender: Yes, so this is the tricky part, which a lot of folks might actually struggle with because this is something which we might not have encountered, if we are new to the whole it if you do not have that much experience around it. So what essentially the swagger schema is, it’s basically a set of guidelines. A set of protocols that UT in that you kind of follow in order to write a JSON formatted definition of a REST API.
Josh: Got it. For the unfamiliar what is Swagger?
Narender: Swagger is specifically a tool that allows you to write API specifications for a REST API. And just like Swagger, we also have inter agent hyper schema as well, which is another tool that allows you to write a API specifications in JSON format for a given REST API, rest based API.
Josh: And so if you’re using swagger, or I can’t remember what was it again, interaction with intent,
Narender: inter agent, hyper schema
Josh: if we’re using these tools, then we we have a good JSON format for external services.
Narender: Yes, yes. So basically, they tell you, they have certain API specifications. If you they tell you that if you want to define a body or if you define want to define a call out or if you do want to define an endpoint, you need to use this keyword with this value. And then you can, that’s how you can approve the designing of an API.
Josh: Got it? Any advice on generating a good schema?
Narender: Yes. First of all, what you really need to understand is the constraint that comes with external services, you can have a really really long schema, but you can only have 200,000 characters in a external service schema. So make sure make sure that every word that you write is making sense and has some real significance in your schema, because you will be if you are writing a schema which is really big, which is which has a lot of words then you might need you you cannot afford to have multiple lines of description for example, for every parameter In the query could be, so yeah, one more important thing is you can also. So use swagger editor.swagger.io, in order to write your schemas fast and you can at the same time at dine at the runtime, you can just verify your schema as well. So that’s a good practice to actually have your schema verified beforehand. Before you just go in and put the schema inside external services
Josh: And is there anything specific except the end of the day? This is getting lined up with Apex, right?
Narender: Yes, essentially, what happens from what I understand is they generate Apex classes based on the definition of your schema.
Josh: And is there anything specifically in that schema that might break Apex if something goes wrong?
Narender: Yes, there are certain caveats to this. My recent discovered and this is a known issue. And it’s quite a disappointing one. So for example you have in your swagger schema, if you have a query parameter, let’s say date. So you will have to define a query parameter as date in your schema. But what happens when you register the schema inside sales forces that same for since data is a reserved keyword in apex, so Salesforce will automatically rename this particular date parameter to Z, zero date. And now if you want to do a call out, you cannot just provide this specific date input parameter because what eventually is going for the call out is zero date and not the date. So that’s a big fuckup. There really, really limits the possible possibilities and usage of the sextant service, but I believe it’s tied for summer 20 Okay, so hopefully some good news after summer 20.
Josh: Because it, is there anything else that like you don’t want to do in a schema, because Apex isn’t gonna like it?
Narender: Hmm. So you don’t want to have a really, really big names because what happens is Apex classes are being generated as you register your schema. So what happens sometimes is when you start to register your schema and try to create variables in your flow, you will get an error that the identifier name is too long. And you will not understand that why did really happen because Apex doesn’t allow you to have, I think 40 more than 40 characters in a name. Yeah, so that’s a big bummer, then.
Josh: So for both the fact that you can only have so much JSON and the fact that Apex doesn’t like to be too verbose, keep it simple.
Narender: Yes, you have to really think about what you are writing, especially in your school. Kima and the naming convention, it should be as small as possible. Because sometimes often what I do is I really, even my class names are so descriptive, especially the method names because you don’t have a limit there. They are so long but I’m eventually starting to realize the importance of having short names and how you can make them work with short this basically meaningful but short into kind of lead into you know, Apex being exposed in flow and stuff like that. This all sounds extremely technical. So how admin friendly kind of be, it can be admin friendly. There are two ways to go about this for admins. If you are really interested in learning how to write the schema, for this, you will have there is a prerequisite that you must understand is how the integrations work. So, if you are really interested then you will you would have to First understand that what API is, what are the basic methods of API, how they work? What are the call outs? What are the input parameters, and all that stuff. So once you have that understanding, it’s very easy to actually write the schema. But if you are not interested in knowing the nitty gritty details of the schema, and you are more more interested in just registering the schema and actually build on that, then you can simply have a developer write the schema for you. And then all the admin need to take care of is just create a name credential, and register the schema and then build on top of that. So all you need to do is just register them and register the schema, then reference that generated call outs or actions in your flows and have the response processed according to your business needs.
Josh: So In essence, once you kind of get past the hurdle of the schema, you have access to a REST API in a very declarative way.
Narender: Yes, very much. So if you can just get the schema, right, it gets really, really easy for, for an admin to actually just do a bunch of stuff with the API without having actually having to write cloud check tests.
Josh: Gotcha. And you mentioned it briefly, you talked about named credentials. How does security on the platform work if we’re working against like an authenticated REST API?
Narender: Yeah. So authentication is sometimes very tricky for a lot of folks who do not understand a lot of authentication protocols. Initially, I used to struggle a lot as well. So most of the API’s, I mean, if you want to just play with them, you will find that it’s not the authentication is not that complicated, and you will probably even don’t have you will not have to do it. authentication. For example, if you do try to do authentication with Google Cloud Vision API. In that case, what the API actually gives you is an API key, which goes into the query. So what essentially you need to do is create a named credentials, where you do not actually pass in any credentials and just say, an authentic, no authentication, something like that. So you do not need to think much about it. And all you need to do is just pass the API key in your query parameter inside your external service call out. But there are for example, then, if you take it up, ticular level up. Then you have username password based authentication, which is pretty simple in name credentials, all you have to do is just create the name credentials with your username and password. And then what and that’s the beauty of it. For that, the platform handles the authentication by itself. And you do not need to actually do the whole authentication process and get the token and actually then get the token and put it inside your headers of your call outs to actually authenticate your requests. So that’s the very big advantage that I see in terms of using named credentials, and not just in external services, but also if you are using it in apex.
Josh: Right, because now you don’t have to like it’s a no code solution for authentic callouts
Narender: yes, iso if your name credential actually is sufficient enough to support all odds, so just to actually coming to one more shortcoming, what I noticed recently, so I was trying to do a Twitter API integration with external services. And what I eventually realized that realize that what we have to tutor is actually a three legged OAuth process, and which is currently not supported in the name credentials. And also, but you actually see auth provider set up as Twitter. So, but when I actually had a conversation with the flow, external services pm on intervention, I’m not sure which one I think she was
So I was having this conversation. And I, eventually I was told that that auth provider was essentially designed for SSO. And they never really thought of actually something like this can be used, as well. So yeah, I guess they are working on it. Something we will see in future as a standard.
Josh: It’s interesting because OAuth is not all created equal. Like everybody kind of has, you know, their own little flavors of it and seems like yeah, Okay, so let’s talk about the front end, how does Flow play into something like using external services.
Narender: So it’s very simple. So if you are familiar with flows, so you’re doing as using an external services in a flow is very simple. All you need to do is just drag the action element from your tool toolkit toolbar here on the left and just put it on the canvas, you search your element or the method that you want to call out. And but when you base after your selection, you will see a list of inputs. If there are any in your defined schema, you will see all those inputs listed and you can just provide the values in the input. And then you have a choice as the flow has progressed you can actually have manually assignment of variables or you can actually you can just simply choose the flow to action care, take care of the output. So we were it will generate the variables for you. So either ways you can go about it. And that’s pretty much it that you need to define the cloud. Sometimes it’s where I have really struggled is defining the cloud is simpler, but actually working with the response is bit more tricky. In some cases, where the response is not as simple as it looks, because too many loops inside a query. Yeah, so
Josh: gotcha. Well into. Okay, so first to remind like, going back to what you were saying before, this is another good reason also to keep your Apex naming short and simple so that it’s a little bit more visible and flow, right. And then also, to kind of talk about the, you know, the response itself. Or there’s some things that external services can handle from a REST API response in some things that they can’t like. Like in the structure of the response from the REST API. Yeah.
Narender: So, talking about the response and going back to my caveat that I told you that if for the reserve keywords, this applies to the responses as well, because you need to define your response in your search external schema definition. So, when you define the schema definition, if that keyword is also is part of a response it gets or right or it gets renamed. So, essentially, you will not be able to access that particular variable or value, right, you will have to just skip that part.
Josh: Gotcha. And how like complex can the response be like can it handle complex objects on return?
Narender: Earlier, it wasn’t possible before. Enhanced external services came into the picture, but now are the enhanced services. Enhanced external services gives you the ability to actually have nested objects. I haven’t really tested the complexity to what level nested objects can go to. But I have I have done about five levels of nested objects with util. API, but and it works fantastically with that. So I’m assuming it might work.
Josh: You haven’t been able to break it yet. Yes.
Narender: Yeah. So for nested objects, it has worked pretty well so far. For all the use cases. I have tested it.
Josh: That’s our show. Now before we go, I did ask Narendra about his favorite non technical hobbies. And it turns out it’s not just football, proper football.
Narender: I love playing football. I love playing basketball, and also a bit of volleyball.
Josh: And, of course when you say football, you mean proper football or not women’s soccer? Yes.
Narender: It is really confusing at times.
Josh: Thanks for listening, everybody and thanks to new render for the group. conversation. Now 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 podcasts. I’ll talk to you next week.