An introduction to the Adobe Developer Console

Transcript

Hello everyone. Welcome to Developers Live. My name is Carmen Sutter. I’m a Group Product Manager on Adobe’s developer platform. I will spend a few minutes today to provide an introduction to the Adobe Developer Console. This is really a basic session for those of you that are thinking about getting started with building with Adobe APIs and services or some of you that are having dabbled a little bit but just want to maybe understand what is possible to do with our products and how to do that. I hope you’ve enjoyed the session so far. Obviously, we’re super excited about the announcements today with Developer App Builder announcing their general availability. I do hope that you are enjoying the conference as a Product Manager on our developer platform. All of you are near and dear to my heart and we look to you as building great things with our products. With that, let’s get started. This is me normally. I will jump back on video in a little bit, but for now I thought we’ll do slides and then jump into a demo. What is the Developer Console? The Adobe Developer Console really is your main interface for managing all of your development activities. Console, we are exposing Adobe APIs, SDKs, event providers, as well as Adobe Serverless offerings, which is Adobe IO runtime. We also have as part of the console access to what was known as Project Firefly and of course is now known as Adobe Developer App Builder. With the Developer Console, we are also providing you with credential and lifecycle management, providing insights on our services, and have debugging and tracing capabilities. Then for those of you that are building with Creative Cloud, if you are building any of the plugins for the UXP platform, Developer Console is the place for you to submit those plugins for approval and listing on the Adobe marketplaces. As I mentioned, the Project Firefly App Builder, and I’m the only one who forgot to update their slides apparently, application templates are accessible from the console itself. Who can access the Developer Console? There are two primary roles, Adobe roles that can use the console. That’s the system administrator of an organization and a developer inside of an organization. System administrators, of course, have access to all of the products and services as they are the ones responsible for managing Adobe instances on behalf of a customer. As such, they also have full access to the Developer Console and all the licensed services that the organization has access to. System administrators are also able to view and manage all the projects. We’ll talk about what projects are in a second. But just know as a system administrator, you can administer all of the developer activities using the Developer Console. We then have a specialized role that is a developer role. And that developer role can be granted and managed inside of the admin console by administrators. These developers have been granted access based on specific product profiles. And as such, have access to the services that are associated with those product profiles. So for example, if you’re a developer who is working with Adobe campaign, and you might be responsible for setting up campaigns, but you might not necessarily have access to published campaigns, you would be getting access to the campaign management product profile. And that’s the access that you would have with the Adobe campaign API. Developers can view all the projects inside the Developer Console. But they can only manage those projects that contain the services they have access to. So that’s actually an important distinction to make is that any of the projects and integrations that are built for an organization in the Developer Console belong to the organization. They don’t belong to individual users and belong to individual developers or system administrators. All projects belong to the org. And so what does that look like in reality? Let’s go check that out. And to that, I’m going to switch over to the Developer Console. So this can be accessed via developer.adobe.com slash console. If you are on our developer website, Adobe.io, you’ll also see a button in the top right to access the console. But bookmark this if you are one of the many developers that is building with our products and services. So as you come in to the console itself, a couple of things to point out. We have the organization that you are part of and the role that you have in this particular organization. So in my particular case, I’m a member of multiple orgs. I think for most of you, you’ll just have one of those in your list. I have a number of those. And then depending on the organization, you’ll also see the different types of services that you will have access to. And I’ll show you what that looks like. You also see like recent projects that have been completed. If you watched the session this morning announcing Adobe App Builder, you saw David Bench build this Adobe Developers Live demo. So this is the same organization. And this is now visible to me as one of the other members of the organization. And since this is one of our test orgs, you’ll see a couple of randomly named projects. So don’t mind that. We have resources generally towards the bottom of all of the pages in the developer console. And I also want to highlight our documentation, which can be found from the footer directly. And it gives you an overview of all the console capabilities, any FAQ questions you might have, also access to support. So if you’re stuck, if you have questions about specific flows, please feel free to check out the documentation and let us know if you run into any issues using the support options that are listed there. In the console itself, we have a list of the projects that have been created in this particular organization. So I mentioned there are a number of those here. We’ll talk a little bit about what these different options are in terms of auto-generated versus not and what workspaces are. But let’s start over here in our browse section. So this is basically the catalog of services and APIs that have been exposed on the developer console by the various product teams within Adobe. We have a collection of APIs that are available from the various clouds at Adobe and you are able to filter by these product groupings. You can also search for services. And you’ll see that in some cases, the option to create a project is grayed out. And in this particular case, it means that this organization does not have a license for this particular service. So the 3D automation API, which is one of our Creative Cloud services, is not available to me in this organization. We don’t have a license for it and are not able to use it. If there are services where I am an admin for a company that has a license, you have the option to create a project. And we’ll go through that flow in a second. But this basically shows you all of the different products that you can use and build with as part of the org. And we have a big variety, a broad variety of services available. So be it Adobe Analytics, Photoshop, we have Adobe Stock, Audience Manager, Content Commerce. So a number of different services for you to build with. I know we have a lot of the experience platform developers that are joining us. So this is the place for you to come check out and access the services that are available based on the licenses that you have in your organization. Besides APIs, we also have a number of event providers that we are making available. And so events are really push notifications. So instead of pulling an API, these notifications are sent to you to a webhook that you have set up or to a runtime action that can respond to those events. And the list of event providers, again, is entirely dependent on the licenses that you have based on the organization that you’re in. A couple of examples you see here is, you know, AEM events, a very popular event provider. And we know a lot of you build with AEM events. The other one that is very popular is Analytics Triggers. It allows you to be notified when certain actions happen based on the analytics data. And so a great service, great event provider that is seeing a lot of usage. We have a number of asset compute event providers, which is the AEM as a cloud service. And these are various instances that are connected. We also provide Creative Cloud events, as well as custom events, and a number of other providers. So this list, again, is populated based on what your company has access to and the events that you might have created as custom events. The next section is plugins. So this is for those of you who are building Creative Cloud UXP plugins. Currently, the developer console supports submission of XD and Photoshop plugins. So if this is what you’re interested in building, use the developer console flow to create a project with one of these plugin types. Those of you that are part of the app builder trial or have purchased IOBuntime, you can also initiate that as part of the developer console and create a project with IOBuntime, which will create a namespace for you and will be the first step to really get you up and running with our serverless platform. And then lastly, in our service catalog, we have a number of downloads. And this is more on the Creative Cloud developer side. So if you are building panel applications or doing some scripting, this is really the place for you to come and get started with the various SDKs that are available for our Creative Cloud products. So this is kind of the quick, you know, what’s available and what’s available for you as part of the organization that you are in and the licenses that you have access to. So I jump back to the homepage real quick. We have a few quick starts as well. Download resources will get you straight to the download section of those SDKs. If you are interested in building with Project Firefly or App Builder, you can use this project from template flow and you can go through the App Builder flow to set up your workspaces and name spaces. I’m going to save this one for last if we have some time. I know there are a lot of sessions that are focusing on App Builders specifically. For now, I kind of just want to walk through, you know, creating a project and consuming some of the services and getting credentials for our services and give you an overview of how those flows work and why they’re interesting or important. One other little comment here is this public profile is needed for those of you that are submitting plugins that are going to be listed on the marketplace or for those of you that are building applications with our OAuth services and basically this public profile is used to populate the consent screen. Your app clearly states who is asking for permission to Adobe APIs, but that’s what the public profile section is for. If you are planning to just build service-to-service flows, this might not really be applicable for you. With that, let’s create a new project. When we go through this flow, a project really is just a container for you to create a new to capture your work. A project can consist of credentials, it can consist of runtime name space, it can consist of event registrations. It’s really just a way for you to organize your work. By default, we just give it a generic name with a number. You can create a project title and project name and especially for organizations that have a lot of developers, a lot of apps that are being built, I highly recommend using this to make sure you provide a little bit of context for the project and what is contained in it. This is our DevLive session project. Let’s update that. The options that I have here, again, this org is enabled with runtime, so I see runtime, but that’s just not an API. In our API catalog here, we give you all the products that you are licensed for. This view by is available to me in this particular role versus all. But let’s just stick with what we’ve been building here. I will go ahead and maybe start with Adobe Analytics. I selected Adobe Analytics, and the service is actually available with two different authentication types, depending on what it is that you’re building. The options that you see here will differ from service to service. Some of the APIs that we offer are purely supporting OAuth flows. Some of the services purely support service to server authentication. And we also have a few services that are really just doing the API key on the server. We have a service account, and we have a service account for authorization. But for this particular piece, let’s go and build something with the Analytics API and maybe connect that to our in-house system, and for that, we need a service account. As we go through this flow, we can generate a key pair for you using the console, or you can use the API key separately. Feel free to use this option. For now, I’m going to stick with the lazy one and have the console create the work for me. And you’ll see that the console will not store that information. Instead, we prompt the developer or system admin to download the credentials for security and going forward, it is up to me to hold on to that information and use it for all of my innovations. You’ll see the credentials listed here. I can add additional credentials. The credentials that are generated from the console have a one-year expiration, as you can see here. One of the new features that the developer console will be introducing this month is to provide you with a notification when your credentials are about to expire. Years are a long time. Many of you have your own processes of managing credentials, but sometimes you could forget that a credential might expire and your services and your apps are interrupted. We are going to introduce notifications both in the UI as well as by email ahead of time, so you are able to add new credentials or new certificates or, you know, take the app offline if you choose to do so. Once, so this is really just a view for you to see what was just generated and copy your public key if you would like. And then the next step as part of any of our GWT flows is to select a product profile. So, if you are, you know, familiar with product profiles, they really are a subset of permissions of any of the Adobe products. They are managed inside of the admin console, and some of these are available out of the box depending on the product, but they are also available for you or you as a system admin or product profile admin can create product profiles. So, in this particular example with Adobe Analytics, you might want to create a product profile that gives access to non-sales data. So, this might be there might be some restricted data that you don’t want everybody to have access to, so you could create a product profile that is just the more publicly available information. In either case, the list of product profiles is entirely driven by you as an organization, and so, when I as a developer come here, the product profiles that I see are based on what I’ve been granted access to, and also what I want to do with the app that I’m building. So, in this particular case, let’s just maybe go with this recommendations group. That’s the one I’m going to build with. And then once I save this, I now have all the pieces in place to go ahead and build my app. We can generate the access token directly from here, just provide you with the technical account ID, and the organization can retrieve the client secret directly from here. So, a quick way for you to really get credentials and get started building. You can download the details for this particular credential for Postman if this is your preferred way of trying out your services. That’s basically what you can do here. Now, this might be just, you know, the first API that I’m going to use for my app, and I might want to add another one. And in this case, let’s say I want to potentially use customer journey analytics. The flow now is a little bit shorter because, you know, we already have the public key created. Again, I’m asked to select a product profile. In this case, I only have one. And now when I click save, I now have a set of credentials that can connect to both of these APIs that I’ve selected. This same project might also want to leverage some of the events. So, I might not want to just rely on APIs themselves, but I could also have event notifications that are part of this app that I’m building. And maybe let’s stick with our analytics theme. I’m going to set up analytics triggers for this particular project. And there’s a few example subscriptions that exist already. Somebody has been testing out abandonment triggers. So, again, I can leverage the existing credentials that have been set up. Now I just need to provide some information on how I would like to receive those events. I could give the registration a name. And then decide on either providing a webhook. That’s my preferred way of receiving events. And if you choose this, you have the option of having events delivered as a single event or as a batch. Alternatively, as a one-time customer, I could also use the one-time actions that I might have created in this particular case to go ahead and have the events sent to that one-time action. Besides those two options, we also have a journaling API. So, in case you might have missed some events or your webhook was offline, you can go ahead and use the journaling API to pull the events yourself. This particular case, I’m just going to go with the journaling approach because I’m running out of time. And, again, we are leveraging the credentials that have been used in this particular case. So, now we can use that same set of credentials for our app to use events alongside the two APIs that we have put in place. And let’s see. As we watch our product do its job. This is why live demos are always interesting because you watch these little spinners. So, I’m going to maybe go back here on the home page while this completes its job. And we will go and take a look and see if that has completed yet. Not quite yet. All right. So, we also, there we go. Here is my events subscription. My dev live triggers have been added. And we see our navigation just updated as well. So, this project now has three APIs. The management API was added automatically because it’s the journaling API that’s used for events. I have my trigger events in place. And once I start receiving events, you will see this debug tracing tab here that allows you to take a look at what’s happening with your events. You know, have they been successful? If not, why have they not been successful? And so, you can use that to help understand why you might have not received events for a particular time period. Alongside the event details, you can also look at an event sample payload. So, making sure that you know what to expect when the events arrive on your side. And you can build out your app to respond to that payload. And we can also send a sample event. So, this has now kicked off a sample event that gets set in this case to my journaling endpoint that I can then pull and make sure that, you know, I know what the event looks like and that it does actually work as well. So, this is our events and service to service integration. I could also create add a runtime namespace to this particular project. And you’ll see I have the success message here. And behind the scenes, I am now getting a runtime namespace set up automatically. These are auto-generated names. So, always makes for some interesting combinations here. But once you have the namespace created, you can now go ahead and set up your environment and start defining some of the actions. Either take actions that come out of the box or define your own. And in each of the cases, you see links to our documentation and then how to deploy the first action. How to set up webhooks. So, throughout the process, you should be able to get the guidance that you need to start building with our products. Once we have used, you know, this app, which we haven’t yet, because we just set it up, you can come over here to the insights tab. And for all the components of this particular project, you’ll be able to see insights both in terms of the API calls and status codes. So, how about that? The insights do have a delay. Obviously, we have not actually made any API calls. I have not used those credentials. But we provide you some data points about runtime events and APIs themselves. So, whichever components are in your project, use the insights tab to understand how you’re using those products over time. I know that we are getting to the end of the session. So, I want to make sure I leave enough time for any of the questions that we have. So, let me jump over if there are any questions in our Q&A pod. There are not. I am happy to answer any questions if any of you want to jump in live. Alternatively, please feel free to reach out directly as well. And we are happy to support you and excited to have you join us today and tomorrow for this session. But more importantly, to have you come build with us. And before I let you go and have you head over to the next session, I want to make sure that you are aware of the chance to win some prizes by heading over to the Experience League booth. And also, all of the sessions that have been presented today and will continue to be presented over the next day will be available as recordings. So, please, if you’ve missed this or if you think somebody would like to learn a bit more about the developer console, feel free to point them to the session. We also have resources available for you throughout our documentation and our support channel. So, excited to spend a little bit of time with you today. And hopefully, many of you will start building using the developer console. And stay tuned for improvements that we continue to make and new services that are continuously added to this console to help you build things of value. I’m going to check one more time to see if there’s any questions. It does not look like there’s anything. So, with that, I think we are at the end of our time. There is one. So, the can you choose particular services within a particular product like Target and Campaign? That is the purpose of the product profiles. So, the product profiles, and in this case, apologies, because we, you know, our test orgs are not set up quite to the extent as you have in your own organizations. But the product profiles provide you that granular breakdown. So, within Target, you know, the different endpoints are really connected to the actual product profiles or controlled by the product profiles. So, that is possible to do. All right. With that, I think we are at the end of our session. And thank you again. And I hope you had a great rest of the conference.