Hari Shankar: Hi, everyone.
Welcome to this demonstration on MuleSoft and our integration platform.
I'm Hari Shanker, I'm a principal solutions engineer with MuleSoft.
And really MuleSoft's mission is to enable organizations to change and
innovate faster by making it really easy to connect their applications,
data and, devices.
And we do this with a single unified product called the Anypoint Platform.
So today what I'm going to do is walk you through how this company called
Northern Trail Outfitters, really a fictitious company, enabled and
exposed mobile user experiences for their customers in a scenario in a world where,
they had M and A pressures, bringing different backend systems and
bringing all of those to drive those mobile experiences.
So as you see here on the screen, Northern Trail Outfitters is your typical retailer.
They sell outdoor clothing, apparel, different accessories.
And they just bought Alpine Nutrition,
which is a healthy whole nutrition company, right?
And the challenge here is Northern Trail Outfitters uses SAP as their ERP,
whereas Alpine Nutrition uses a different system right, Commdex.
And for this mobile initiative,
they need to bring the inventory product detail from both of these systems and
drive that unified experience, so let's see how they do that.
This is the API led connectivity approach, that Northern Trail Outfitters embraced.
And as we see here at the bottom, we have Northern Trails SAP instance.
But then they also brought in the Commdex,
which is really a MySQL database behind the scenes.
And exposed both of these as well as other backend systems as model and system API's.
What that enabled them to do is firstly standardize their backed systems.
Because now whoever is building those mobile experiences do not have to
know that there is an SAP, know that there is a Commodex or a database,
maybe a Salesforce or other systems.
All these users of these backend systems are interacting with our API's,
very modern, very easy to understand, and very easy to consume.
What they did after they exposed these backend systems is,
as we see here, the belt of process API for an order 360.
Let's say, these are domain process API's.
They also build customer domain APIs, product API's, and so on.
And then as they embarked on their journey to enable these mobile experiences,
they then created this customer 360,
which now leveraging the assets that they have already built out.
So as we see here, this approach enables a lot of reuse,
a lot of standardization and hence a lot of speed in the end.
Now once a customer 360 was exposed, what Northern Trail Outfitters
did is support different end user experiences, right?
So as we see here, they were certainly able to support their mobile initiatives.
They built a mobile experience API that called out to the customer 360, and
then a few other process API's, order fulfillment and
maybe others to drive that mobile experience.
Now, then Salesforce Service Cloud, Salesforce Sales Cloud,
Salesforce Commerce Cloud initiative came came about.
All they needed to do was create an additional experience API that caters to
those end user experiences.
So as an approach, this API led connectivity approach,
loosely coupled your integration landscape, it drives a lot of
reuse by enabling you to create these reusable building blocks.
And then as we enable different end user experiences,
it becomes really easy for you to reuse those backend processes and
create these experience API's that cater to different experiences.
So now let's look at the product and see how MuleSoft and
the Anypoint Platform enables this API-led connectivity approach.
So I'm now logged in to the Anypoint Platform as we see here.
And within this dashboard, I have my design experience.
Which then drives into my implementation and
yeah unit testing debugging experience, right?
And then operationalization, a number of different options, but
then certainly within Runtime Manager you can deploy these API's on-prem,
in the cloud, any combination thereof.
And then the whole monitoring visualization, governance aspects that all
built in, and are available, accessible from the single pane of glass here.
Exchange down here is that asset repository that marketplace where MuleSoft
publishes a number of different assets based on best practices that we learn
from our engagements with over 2,000 customers in the space.
As an organization using MuleSoft and the Anypoint Platform,
you will also have your own private exchange, where you can publish assets
that are relevant to your organization and drive easy discoverability and reuse them.
So let's go to the exchange and look at some of the assets that
are available there and see how the platform works.
I'm going to jump in to Exchange, and
as we see here we have a number of different assets here.
And I have two categories, well a couple of categories here, right?
So the one down here provided by MuleSoft is a public exchange.
And this is where we publish all our connectors, connectors to over 200
technologies that makes it really easy for you to drag and drop and
connect to an SAP or a MySQL in case of Commodex, or whatever backend system.
So if we go into one of these connectors, let's take the Salesforce Connector.
[COUGH] As you see here, very well documented,
very easy to self-service consume.
But then also within this Connector asset, we have a number of different
examples templates published as well that use these connectors.
And if I go back here just like the Salesforce Connector,
a number of different connectors as we see here, those are SAP connector as well.
And the level of documentation and
the consumerability is consistently across all our connectors.
We also have a number of templates published on Exchange.
So if I open up this category box as you see here, not just connectors but
templates examples, API policies, just a bunch of different assets
that enable our customers to get up and running really, really quickly.
So if you go into templates, a bunch of templates here, and
I can very easily search for, let's say,
templates that are relevant to Salesforce connectivity.
And here are a number of templates.
And if I go into one of these,
this is the Salesforce to Salesforce account broadcast template, right?
So again, well documented screenshots that show exactly how the flows will work.
And you can import these flows into a development environment and
use these as a starting point for your development.
So it drives a lot of speed but then you as an organization,
building on top of Anypoint Platform,
you get to leverage that knowledge base and drive your success.
Hari Shankar: So if you go back into our asset catalogue,
let's go into the private exchange here and
look at a few assets here, that are relevant to Northern Trail Outfitters.
So if I remove the filter, so as you see here,
Northern Trail has built out a number of different API's and
published on Exchange for self-service discovery and consumption.
I'm going to search for an order API, just to see what exist there, right?
because I want to consume orders and build my mobile app on top of that order's API.
And as we see here, we do have an asset that's already been created.
This Orders API, frontends a couple of Orders API.
So Northern Trail had their original SAP order API.
However, when Commodex came into the fold with Alpine Nutrition,
they just created another Commodex system API.
And then within this process orchestration,
Proc API, they just incorporated that additional ERP, right?
So really easy for you to bring in systems, sunset systems,
as needed without impacting consumers that sit on top here.
And with all our assets, these assets of very interactive as well.
So you certainly have your documentation, but if I want to interact with the API,
let's say, and see how this works, what's the behaviour?
I can do that here to the marking service that has been exposed.
So certainly mandatory parameters are all pointed out to you and
validation is all built in, right?
So you know, it requires an order ID.
And then if I go here, we need to just provide an authorization,
client ID and secret.
And as we see here, we are able to interact with this API mocking service,
just like we would with the live API.
It makes it really easy for somebody who's looking to consume this Orders API to come
in and see how this works, how this behaves, and then incorporate this, right?
I can also as a consumer of this API, and I'm a mobile developer, let's say, I
can start building my mobile applications just by using this mocking service.
Because this mocking service behaves exactly like the implementation
work, right?
And we can drive parallel development in that fashion.
And whenever the service is ready, all the mobile developer would do is swap out
the mocking service with the live implementation, and
the mobile app should be ready to go.
So lot of speed acceleration to parallel development driven by a mocking
service and these assets selection.
So that's the system API that we just saw here.
Now, if you go back to the asset list, let's look at a few other APIs.
And going to look for customer APIs here.
And as you see here, we have a customer API published here.
This is a process API that calls out to multiple system APIs and
creates that customer domain view.
And within here, as we see,
there is also Customer 360 that then calls out to the customer domain API.
And in this case, the Order API, right, and
creates a Customer 360 that combines customers and
their order information, which is then exposed to different experiences.
So let's go back and look at an experience API here.
And I'm going to look for mobile experience APIs.
And we do have a mobile experience API called a Mobile Customer API here.
So this lives in the top layer as we see here.
And if you look on the left, the operations that are exposed on
the experience API, are very different from what we saw that system API's, right?
We have search functionality, we have our product look up, orders functionality and
things like that, which is typically what you would expect from an experience API.
And as a mobile developer, if I want to consume this API and
leverage the customer data that's sitting in,
SAP formatics in this case, all I do is request access
right from here and I'm asked to create an application.
I do have an application here,
and then I can choose which version of the API do I want access to.
And APIs our versioned,
APIs are treated as first class citizens within our platform.
And just like any first class product,
you can have your users on N-6 version adoption cycle.
And then you sunset versions and have your users adopt a newer version and so on,
upgrade their versions.
So here I can think which version do I want access to.
And you can set up different SLAs depending on what kind of access and
what kind of end users are requesting access.
So you may have developers requesting access to a free tier to
build the applications in the dev environment.
But you may have a premium tier SLA that will be consumed by your users in
their production environments.
So if I request access here, in this case, our access has been set up automatically.
So I'm immediately granted access access and I have my client ID client secret
available here to start building my applications.
You can also set up manual approval workflows within this process.
So certainly for your production level access,
you probably want an API administrator to go in and grant access after reviewing
who's requesting access, and all of that is supported by the platform.
And now, as a mobile developer, I'm ready to leverage this API and
build our mobile applications.
So if I go here,
here is a mobile app that Northern Trail Outfitters has built and exposed.
And as we see here, they have the SAP data, the apparel coming from,
you know SAP.
But then, we also have the Alpine Nutrition products coming from Commodex.
Also phased within this mobile app, completely transparent to the end user
that these are coming from different backend systems.
So if I quickly refresh this,
let's log in and start shopping.
And so I'm going to add a jacket here to my cart.
Let's go ahead and do that.
[MUSIC]
Hari Shankar: And then I also want to add,
let's see cranberry bar because I like cranberry bars.
And let's go ahead and check out and as we see here,
my payment method is all set up and then I can place an order.
For the end user, as I mentioned earlier, all of this is transparent.
The fact that, different back end systems are in play, different processes are in
play, and everything is being driven by that top level Mobile Experience API.
So that's how MuleSoft drives connected experiences.
And what you saw today, just to summarize, we looked at how MuleSoft
enables very easy connectivity with our out of the box connectors,
our 200 of those, in our case, to an SAP and our Commodex database.
We then saw how within a process API MuleSoft enables creating those
business processes, your business logic and
orchestrate different API's to support different initiatives,
mobile initiatives, whatever your initiatives and projects are.
And then within the Experience API, we saw how Anypoint platform enables
driving different end user experiences to reuse, right?
So mobile experiences, all you do is create a Mobile Experience API that
leverages our Customer 360 and an Orders API.
If you're driving web experiences,
all you do is create a new Experience API and then you're ready to go there.
So speed, ease of connectivity is really what we do, and
really the best platform in the market today to do that.
Thank you.