Nina Rosen is a Salesforce developer and an architect for Neomatic over in Germany. She has built integration apps for a variety of platforms and companies in the past and is currently working on a partner relationship management system based on Salesforce data.
In this episode, Nina and I talk all about integration with Salesforce. Specifically, we discuss the various aspects of integrating Salesforce with other platforms. Listen in and learn how you can do it yourself.
Show Highlights:
- What OAuth is.
- The distinctions she has found across implementations with OAuth.
- How to get the API you’re integrating with.
- What she does to structure Apex to make it friendly with different call-outs.
- Tips for handling the different kinds of incoming and outgoing data formats.
- Considerations for the API being called into by Salesforce.
- How to protect yourself from an attack vector.
- Microsoft’s new Graph API.
- Things to consider when working with user interfaces.
- How she has worked around the lack of a patch method in Salesforce up until now.
Links:
- Nina on Twitter: https://twitter.com/nina__mdt
- Nina on LinkedIn: https://www.linkedin.com/in/nina-rosen93/
Episode Transcript
Nina Rosen:
Somehow I’ve grown up in a household where computers were present since I can remember. So, internet was something which… I have grown up in the internet actually.
Josh Birk:
That is Nina Rosen, a Salesforce developer, and architect for Neomatic over in Germany. I’m Josh Birk, your host for the Salesforce developer podcast, and here you’ll hear stories and insights from developers for developers.
Josh Birk:
Today, we sit down and talk with Nina about various aspects of integrating Salesforce with other platforms, starting with an introduction to Salesforce.
Nina Rosen:
I started an apprenticeship at a consulting company or consulting and product development, and the customer decided they want to go on Salesforce and we were doing prior the [inaudible 00:00:53] development. And so, we decided to be part of the solution instead of part of the problem.
Josh Birk:
Nice.
Nina Rosen:
And, that leads to that I was, I think, two years in the company and was somehow starting to managing the Salesforce side of the project.
Josh Birk:
Got you. And then, describe your current job to me.
Nina Rosen:
Currently I’m building an app, which is my first step that’s not an integration. It’s a partner relationship management system based on Salesforce, and based on the financial service cloud. But, prior that I’ve built Integration apps for IBM, and IBM stuff, Microsoft stuff, and played around with quite some other APIs.
Josh Birk:
Got you. And, that’s our main topic today, as you have done a lot with, like you’re saying [inaudible 00:01:53] IBM, Microsoft, SAP and more, but let’s talk about a little bit the basics of integrations. A lot of integrations are authenticated and much of that is by OAuth. So, first to level set for everybody, what exactly is OAuth?
Nina Rosen:
OAuth is authentication standard or actually these are two authentication standards, which is one is just OAuth, and the other one, the current one is OAuth 2.0. OAuth 2 is a lot about different kinds of flows. You can have to authenticate users, how you can make sure… It’s a lot about authenticate users and making sure that you have matching identities between systems without needing to store password of the user in another system. And, it also defines how you can define a scope, how much information a user or not a user servers can access on your other side.
Josh Birk:
Yeah. I always… When I was talking to audiences about OAuth and asked them if they’d ever encountered it, and when people said, no, I’m like, “Actually you probably have, because anytime Facebook asked you if you wanted to allow game XYZ to use your credentials, well, congratulations, you just used OAuth.”
Josh Birk:
But, as you were mentioning, there’s different kinds of OAuth, and we’ve got things within Salesforce that like name credentials all the way down to JWT tokens, do you have a preference for the kind of OAuth flow that you use?
Nina Rosen:
I really like the bearer token OAuth flow because it’s somehow the simplest flow, which has not so much errors you can do so easily, where you could break your whole security system. One of the easiest errors you can do is encrypt information in your state. There shouldn’t be any information, otherwise, you are open to attacks.
Josh Birk:
Got you. Nice. And, more on that, OAuth is considered the gold standard, but how much of a standard is it really? What distinctions have you found across implementations with OAuth?
Nina Rosen:
OAuth is a standard that it allows you things to do that other standards don’t allow you. You can, for example, we named variables or there are mandatory variables, which are not mandatory, so they are defined as mandatory, but later it said, they can be replaced. So, implementations of OAuth don’t fit to each other all the time.
Josh Birk:
So, it’s a standard with a little bit of flexibility. Has that caused any problems for you in the past?
Nina Rosen:
Yeah, it has. I think it was working with IBM connections while using IBM connections as service provider and Salesforce as identity provider. We were trying to get it work with the standard implementation. You having the named credentials, but it wasn’t working in any way. And, there were a few things that were different. There were renamed attributes. There were attributes you weren’t allowed to set on the IBM connection side, and all of this leads to that we had to rewrite the identity provider on Salesforce, which can be quite a challenge because Apex is good but…
Josh Birk:
Right, but not really designed for that kind of task. I totally understand. Okay. So, once you get past these hurdles, you’ve got your token, you’ve got your authentication, how do you get to know the API that you’re integrating with?
Nina Rosen:
Most of the time I just start throwing random things on the end points I know for the API, and look how it behaves.
Josh Birk:
Got you.
Nina Rosen:
Where are the limits, what happens if i don’t put any attributes in? Yeah, just checking somehow the boundary cases.
Josh Birk:
So, that’s like test driven development, but for APIs.
Nina Rosen:
Yeah. Essentially yes. And, I think you could do test driven development for integrations really, really well, because you really know what you want it to happen at the end.
Josh Birk:
Right. Because you’re expecting, I guess, not just a kind of response, but you’re expecting like a very specific chase on format to come back, right?
Nina Rosen:
Yeah, and don’t need to be chasing. You can also get some XML back or sometimes you even get plaintext. And so, but you know what you expect and you know that the answers, if you do two times the same question in an acceptable timeframe, you get the same answers, at least somehow.
Josh Birk:
Right. And then, coming to the Salesforce side of things, what are some things that you do to structure Apex to make it friendly with these call-outs?
Nina Rosen:
I think the most important thing is put all the hard work in a hyperclass. Don’t try to have your rear call-out in your business logic or in your transformation logic, split it. Say, yeah okay, this is the call-out I make. And then, doing maybe the on-gripping if I have some gripping around the answer and keep it out of your main code.
Josh Birk:
Interesting. So, is that in case you need to make different call-outs with different classes or what’s the big net gain from that?
Nina Rosen:
Mostly it keeps your code readable and understandable for somebody who isn’t familiar with what you are doing in the call-out.
Josh Birk:
Got you.
Nina Rosen:
Especially pausing without a type or untyped chasing pausing can be really, really hard to read. And so, it’s better to not surface it to somebody who just want to understand the business logic.
Josh Birk:
Got you. Well, a follow-up on that. Do you have any tips with Apex and how to handle the different kinds of formats of incoming and outgoing data formats?
Nina Rosen:
I think if you have a very stable answers, you can do the pausing directly and Apex classes you created for the data structure. But, if you have dynamic answers, it really depends on what information do you need. Sometimes it makes sense to pass it into maps or maps of maps, so it really depends on your use case then. But, I think, get familiar with dynamic Apex because it saves you a whole lot of time.
Josh Birk:
And, going to another thing on the platform, what use cases have you found for platform events?
Nina Rosen:
The use case i like platform events that most for using them for push notification for errors. So, I try to keep the noise low on platform events, because I think most integrations that I’ve built so far were on time-critical. So, if I need to wait for five minutes, that’s okay. I don’t need to have something which works instant.
Josh Birk:
Right. Well, so that’s actually something that, back in my consulting days, I ran into all the time, and I’m curious as to your experiences on it. I would always have clients who are like, “We need this answer in real-time,” and I’m like, “You don’t. You actually don’t.” How many business use cases have you found where the actual phrase, a real-time response, was something that the customer actually needed.
Nina Rosen:
Quite sometimes actually. If somebody is searching on another platform, you want to have the results in real-time, but you don’t want to catch this with that on Salesforce. So, there’s again no need to do platform events for near real-time or real-time behavior, and I think that’s a big point.
Nina Rosen:
If you need real-time, better do your i-integrations instead of trying to pump the data into Salesforce. And, try to build up a real-time connection with all data, because you don’t know what the user will be asking. And, if you already know what the user is asking for, you can get it in close to real-time depending on the system. Sometimes you need some kind of middleware which orchestrates you calls but, I think, this shouldn’t be the problem.
Josh Birk:
Got it. Now, one of the oldest ways of having two systems to talk to each other is just good old fashioned email. Have you had any solutions that have relied on that?
Nina Rosen:
Yeah, and I’m not proud of it. But, I think, it was a JIRA integration, which worked way better than using the JIRA API spec then, but it was working so fine that I needed to stop the customer to use it actually because it was creating also some bugs.
Josh Birk:
Nice. Nice. I’m with you. I’ve been there, and it’s kind of one those once it works, it works. I walked away from it after that. So, talk to me about considerations on the other side of the fence. For instance, if I’m Salesforce, I’m calling into an API, what are some considerations for that API in terms of what kind of user should that API be representing and what kind of access should it have on the system to actually get the job done?
Nina Rosen:
I think that the best way for this is to have a user that is calling from Salesforce. So, I don’t like if I have to do the security or not the security, the sharing and stuff in my code. I want to have that I call the system and say, get me the data in the name of this user, or even better I have the credentials via OAuth of the user I want to make the call on behalf of.
Josh Birk:
Right. No, that makes a lot of sense because if we think of the layers that we’re talking to, if Salesforce is calling the API, then Salesforce is basically the client and the client shouldn’t necessarily be trusted, right?
Nina Rosen:
Yeah, definitely. And, I think, you also never should trust your answer. That’s I think the next point, when we’re talking about trust. If you’re calling an external system, you can get every answer and you expect something, but you shouldn’t rely on that you get back what you expect.
Josh Birk:
Because if the server isn’t representing you as the user, then you might be getting either different data or data that you’re not supposed to be getting.
Nina Rosen:
Not only this case. Maybe somebody has replaced the server I’m currently calling. So, it can be an attack vector every integration actually. And, if you trust the user input or the input from the other server, you shouldn’t trust either of them, then you can get into really, really bad places really quick.
Josh Birk:
Interesting. Are there specific steps that you do to protect yourself from that kind of attack?
Nina Rosen:
Yeah, somehow. I think the easiest step is to do the normal input sanitizing, like getting rid of corrodes, getting rid of special characters you don’t know, or you know but you know they’re bad. So, sanitize your inputs and sanitize your outputs if they are an input from an API, because in the end it’s, again, user inputs and you don’t know how well sanitized they are.
Josh Birk:
Right. No, that’s an interesting consideration because, I think, I frequently think of API integrations as very… Salesforce calling a system, getting an answer, doing something with that answer, but if Salesforce itself is the man in the middle, that if you don’t sanitize your information you’re basically setting yourself up to be the man in the middle attack.
Nina Rosen:
Yeah, definitely. And, I have been stopped in security review because of this, so…
Josh Birk:
Really.
Nina Rosen:
There are some people looking on this and, I think, it’s really important and it made me way better in programming to have to go to security review with my own OAuth implementation which are interesting.
Josh Birk:
So, thank you IBM for having to create your own identity provider, right?
Nina Rosen:
Yes. In the end, it’s worth it. It’s a place where now that I can talk confidently about OAuth.
Josh Birk:
Nice. Nice. Let’s go into some more of the specific projects that you’ve worked on. For instance, what was it like integrating Microsoft Teams with Salesforce?
Nina Rosen:
Integrating Microsoft Teams was done as in product development, and it wasn’t the beginning. It was like, oh, no, nothing is working, because we decided for going to the graph API and the point where we started, it was just released the first stable version. But the stable, you really, really need to take with a grain of salt. It sometimes feel like the stable version is more of changing the beta release of the API.
Josh Birk:
And, for the unfamiliar describe… So, this is Microsoft’s graph API, is that right? Can you give us a description of that?
Nina Rosen:
Yeah. The graph API is like the new unified API endpoint for all Microsoft products in this 365 family.
Josh Birk:
Got you.
Nina Rosen:
So, it’s a new way to go, but it’s not finished yet. It’s work in progress, but you can do really cool things with it. And, I left the company where I built it, but I just got a demo yesterday [inaudible 00:17:12] and it was really cool and it’s getting faster.
Josh Birk:
So, what were some of the problems that you’re having with the “release version”? Was it performance or was it not responding? What kind of things was it doing?
Nina Rosen:
I think it was not responding. Responding really slow. And, the worst thing was changing the type of answers you get, depending on the release and sometimes depending on the server you are on. So, sometimes the US server worked, but the European ones not, and sometimes the other way round, and you don’t know on which server you currently are.
Josh Birk:
Okay, yeah. No, that sounds like fun. But, flip to the other side, what cool things were you doing with that API?
Nina Rosen:
I think the first thing we were doing was search, which is kind of boring, but kind of cool because it gives the user the view into the other system.
Josh Birk:
Got you.
Nina Rosen:
The next step was simple. We said, yeah, okay, you can bookmark, you save the search results on the custom object on the standard object and say, it’s what you’re standing on. So, this was a very easy way of integrating another platform with Salesforce, and we were doing the authentication with this standard net credentials, which were really, really nice. And, I think, took away like two months development.
Josh Birk:
Nice. So, talk to me about working with the user interfaces themselves. What kind of considerations should people have if… Because you’re working with two UIs that you’re not under the control of, but you’re sometimes you’re trying to bring those two things together. What are some pitfalls that people can fall into? What are some tips and tricks you have for that?
Nina Rosen:
We never tried to integrate the UI Office 365 into Salesforce because the design [inaudible 00:19:25] doesn’t fit to each other. So, we did every call over the Apex, and we had a custom front side component. I think it is working in an hour and all with standard components, and when needed SLDS.
Josh Birk:
Got it. Got it. Okay, so moving to another integration, SAP is probably a very common platform for people that need to talk to you. What are your experiences like working with SAP?
Nina Rosen:
With SAP was quite pleasant because, I think, I was integrating with the SAC, so the SAP analytics cloud. And, it were like a standard, the standard integration already built there, so it was just clicks, no code, no map working. And, I think, we had it up in 10 minutes, but just because the identity provider needed time to be published.
Josh Birk:
Wow. A 10 minutes solution. So, walk me through the components of that solution where you’re using zero code. What were the parts of the platform you were using? Was that name credentials, was that… What kind of call-outs was that et cetera.
Nina Rosen:
The setup steps for integrating SAC with Salesforce were essentially creating a connected app in Salesforce and enable the OAuth settings and use the OAuth information from your connecter there in SAP and the SAP connector for Salesforce, click save and click run, choose your objects and you will have your data in like five minutes in USCC.
Josh Birk:
Nice. So, I guess that’s an interesting part of building out these integrations is that you have solutions where you have to build your own identity provider in Apex all the way to basically button click and having that data exposed into custom objects. Nice. So have you ever had integrations go horribly wrong.
Nina Rosen:
Yes. I was doing integration with the call center provider, with a call center software provider and the developers of the platform of the call center platform didnt understood that saving the change of a return URL in their system where I give some secret on isn’t a good way to do an integration. And, they were trying to build up OAuth on their site, but they failed horribly because they somehow managed to create a process that leads to that if the user were connected via OAuth, they always had admin rights.
Josh Birk:
Oh, no.
Nina Rosen:
And, this were the point where I said, “No, I don’t want to work on this solution anymore because I can’t say that this solution will ever be secure.”
Josh Birk:
Right? You don’t know how to prove that you will do no harm there. That’s crazy. And, I love how that brings that back full circle because you’re talking about both testing against your integrations, but also, is the API that you’re working with, is the other partner you’re working with a trusted partner kind of thing, and in that case it sounded like the answer was definitely no.
Nina Rosen:
Yeah. And, I think, that’s an important part about integrations. You need to know if you can trust your partner because you are exposing, especially if you are [inaudible 00:23:27], you’re exposing customer data to another system. So, you are responsible for taking care that the other system at least meets basic security and safety features.
Josh Birk:
Right. Right. Okay, out of all of the projects that you’ve done, do you have a favorite solution? I know I’m asking you to choose your favorite of your children, I understand. And, you may pick a couple if you would like.
Nina Rosen:
I think my favorite is the Office 365 solution, especially… Oh, It’s Microsoft 365. Everybody says Office, but it is Microsoft.
Josh Birk:
Got you. Got you.
Nina Rosen:
This is, I think, my favorite solution because it measures a lot longer than all other things. And, I think, the funniest one we’re doing a notes integration in three hours where I did call-outs to Notes, changing an appointment, and I had to button on the appointment in Salesforce where you can say send, and you got the appointment back. So, if there was a change in Notes it was changed there, but this wouldn’t… There would be no way to scale this solution, but it was funny how fast it worked.
Josh Birk:
Got it. Nice. Okay. And then, this is just almost trivia at this point but after many years, Salesforce is finally getting a patch method. Talk to me about some of the ways you’ve worked around the lack of that method in the past.
Nina Rosen:
I’m so happy [inaudible 00:25:15]. Yeah, I think I was… The one time we built some middleware, which were just changing your call to patch. And, I think, in another use case, we needed to send patch calls to the other system because patch calls were posts and in the patch call you could have then a patch call so we were essentially sending similar operation patch calls to the other platforms. So, I’m really happy that it’s here because essentially it’s five letters. No, its six. I think it’s six letters, and it shouldn’t be a problem to build up a whole new server.
Josh Birk:
And, that’s our show. Now before we go asking after Nina’s favorite non-technical hobby, well, it got a little complicated, but at least I managed to bring it back to the pandemic.
Nina Rosen:
Not really, they were all technical. So, I think the least technical were photographing on film.
Josh Birk:
Oh yeah. No, that definitely counts. Are you still doing photography?
Nina Rosen:
Sometimes, but not so much as I would like to but, I think, that’s my fault. So, it’s okay. And, I think, if another non-technical hobby, food. It’s definitely a hobby.
Josh Birk:
That’s definitely a hobby. That’s actually one of Faithful’s favorite hobbies. One recently was just baking because the kids they’re not going outside as much, so they’re baking a lot.
Josh Birk:
I want to thank Nina for the great conversation and information, and as always I want to thank you for listening. Now, if you want to learn more about this podcast, head on over to developer.salesforce.com/podcast, where you can hear old stories, see the show notes and have links to your favorite podcast service. Thanks again. And I’ll talk to you next week.