Product Update: What's New in UAC 7.3
Discover UAC 7.3, including secrets management and security updates, inbound webhook support, user-defined critical path endpoints, and expanded container and cluster support.
Hello everyone and welcome to Stonebranch Online 2022. Today's session will be on what's new in Universal Automation Center 7. 3. I'm Lauren Tancini, and I will be your moderator today. Today's session will be presented by Colin Cocksedge, director of Product Management at Stonebranch. Let's go ahead and get started. Colin, take it away. Thank you, Lauren. Okay, welcome everybody. So our traditional session of looking at new features in the product, we pushed out a release at the end of last month, beginning of this month. Really just want to spend the time covering it so that there is, as always, lots and lots of content to cover. And we will be taking questions. So please enter questions if you have any as we go through. And I'm hoping we'll have plenty of time at the end to answer them. But as I said, lot of content, lot of things that I want to cover. So in terms of UAC, there's five main topic areas that we want to cover, but a lot of these are related. So we're going to go through these little bit of a live demo in terms of looking at some and see how some of these hooked together, how they're related, why we've done things the way we've done. But we're going to look at one of the first things here, secrets management security updates. So in the secret management side, really this has become a much, much more important topic as companies have gone more to cloud- based and hybrid based deployments. So it's become corporate- wise a really hot topic. So there's some exciting things that we've done there. Also with our universal integration platform and the integrations that we provide, we've made, again, leaps and bounds in the capabilities that we've provided there. And I've got some, I think some really exciting news, some really key things that we've got going on there. And also work on analytics and enhancements, the critical path, and we'll cover what that means, general sort of worker automation updates, platform support, stuff that we do, bread and butter within the product there. So starting off with the... Or before we get to the secrets updates, just one little update on the user interface. So one of the things that we spent a lot of time doing with the user interface was the 7. 2 update was a big change. One of the initial feedbacks we had was that people wanted to have the banner color back. There were a number of reasons why that was excluded, but we've listened, we've put that back. You have that capability so that you can now differentiate between the different environments that you may run just to make it easy. It's kind of heads up and front and center with the caliban there. So there's some good news there. So for the secrets' management, a number of things we've done. The first is integrating third party secrets managers into our credentials, and we'll talk about that in just a second. Personal access tokens for the web service APIs, which have a number of knock on impacts to a couple of different areas, and we'll discuss those. We've added OAuth 2 authentication support for email connections, and there's some additional options for agent security, primarily for using agents within the container realm, whether that's Docker, Kubernetes, Red Hat, OpenShift, et cetera. So if we get into the third party secret management credential integration. So the idea here is that traditionally we've stored the credential, the secret information, the password, the token, the key, whatever it is within the credential. And we now have the ability to integrate that to a third party manager and we're supporting a number of them. Obviously we still support our own universal controller credential store as the secrets manager, but also then AWS's secret managers as US keyboard and the cyber credential provider. And we've already had some feedback of some other tools out there that people are using that we need to be looking at. Hasi Corp is one that got mentioned several times. So we'll be looking at that for future releases to extend that capability. So effectively what we have now within the credential, and we have a credential definition here on the screen, is a new field called the Provider. So by default, when you open up a new one that'll say Universal control and that'll behave as before, but you have the option then to select whichever secrets manager you want. So the example here is with AWS's Secret Manager. So you'll provide whatever the information is you need to access that secrets manager, and then you'll provide the key information for the different secrets that you want, so the password, the passphrase, the token and so on can then be pulled from that. And what happens is that will be pulled at execution time. And what we found there is that we've also followed the recommendations for each of the providers for things like cashing and refreshing those as we need, as those get updated in those systems. So we've had some good feedback from this feature with people that have implemented the seven three release already. It seems that a lot of people have gone in and used this integration and had great success with it so far. So on the web service side we've introduced a personal access token concept. So each user now can generate personal access tokens for use with various external applications or use with the API. And they have another use which I'll discuss in just a second. So you're able to generate these tokens. Now bear in mind that when you generate them the secret information, the actual token information is only available when you generate it and then it goes away. So you will need to copy that, put it where you need to have it, manage it, your secrets' manager, whatever that needs to be. And then you can use that, primarily it's used with the APIs. What we see there is that, I've got a couple of cool examples here, couple of different ways to do it. The recommended way would be to put in a header authorization header with the bearer token there we can see the token as part of the request, but we've also allowed access to it via a query parameter on the URL. And when I get into talking about some of the other features that we've implemented, this becomes a useful function in terms of third party applications that don't necessarily give you the ability to pass a header in that you can have that as part of the URL. Particularly, this gets into some of the stuff we're going to talk about with web hooks and so on. So basically also we provided new API points to manage these, to create them, to revoke them, to list them and read the payloads there, and so on, and so forth, option from that. And we'll take a look at some of that as we get into some of the other demos there. One of the side benefits of this is it allowed us to fix an issue that certain customers have had that are using single sign on. Single sign-on users have not been able to authenticate to the promotion targets. So we've allowed the ability to use a personal access token so now a single sign- on user can go ahead, generate a personal access token and use that to authenticate to a promotion target in order to do the promotions there through the UI with their own user ID as a single sign- on generated and synchronized ID. Okay. And we've added OAuth 2 authentication support for email connections and provided support for a couple of providers there and obviously we'll solicit feedback to what other providers might be required there to do that from that side. All right. So on the agent side with the containers, couple of things we've done is that we allow you now to optionally assign the business service membership upon registration. So effectively this is a parameter that can be passed to an agent either through the configuration or if you're using a container, it's available as a variable so that you can configure that agent when it contains to become part of a business service, which means you can have predefined security for those transient agents. The idea with the containers is the agents register, they run their work, whatever their container is designed to do, they get decommissioned and then they're decommissioned also in the controller because they're transient. So the idea there is you really don't have a set piece of infrastructure that you can provide the capability in order to have preset security for, this allows you to have that predefined and then it comes in as part of that business service. We've also allowed you for clusters to put a restriction on the cluster so that the business service membership of the agent that's trying to join has to match the business service definition within the agent cluster. So an extra level of security to stop people randomly assigning agents to business services that shouldn't be there or to agent clusters that shouldn't be there. And also to that end, we put a limit or an optional limit on the number of agents that can join a cluster. So again, for certain purposes we've had requests in that people wanted to say I only want to have a set number of agents in this cluster. So we enabled you to hard code a limit for that. Okay, so on the integrations on the UIP side, we've got a couple of interesting things. And the first one I think is probably the most exciting and we'll get straight into that is that we now support basically inbound web hooks. So previously we've always had inbound APIs. You could always code an application to use our APIs to do whatever you wanted within the environment because we have APIs for most of the functionality that you would need out there. Obviously that's still an ongoing project, we're still expanding that as we go. The idea here is though that most modern applications and infrastructures provide the ability to publish a web hook. In other words, they're doing the monitoring for us and they're basically saying, hey, there's an event that I can publish that you can subscribe to, so we can subscribe to that event. And what happens there is we have the ability then to receive that payload and we don't necessarily have to know everything about that payload up upfront. We just received the payload allow you to trigger, allow you to process on it and then extract information from that payload. One of the big advantages of this, or there's couple of big advantages is that when you get into things like event monitoring, this gives us, I would say almost unlimited capabilities for creating event monitors and it does it without polling. So we're not going out to an external third party application and querying it. The file monitors today that we have the work with the agent and with the remote FTP monitors, they do it on a polling function. So they go out and they basically say, okay, periodically I'll go and check that the information that I need, is it there, is it not there? Should I trigger on it? Should I not trigger on it? In this case, this is an inbound and the processing is handled by the remote application or the remote infrastructure component. So we're not doing any polling. This because become key in cloud infrastructures because a lot of things like API calls get charged for and although it's fractions of a fractions of a penny or a cent or euro or a Euro ascent that mounts up if you're polling every 30 seconds for 24 hours a day, 365 days a year in order to check that, let's say a file has arrived in the S3 bucket, something like that. So we've provided that capability there to do that, to give us that there. Now I've got a number of slides here that go through this, but I'd like to go through this in a live demo and skip over the slides and we'll leave this as a reference for you when you get the materials from the presentation. So if we switch over to a 7. 3 controller here, see a number of things I have. So one of the things is that in 7. 2 we introduce the universal events. So I have a template here that I've created to catch S3 events. So what I have to do is create an inbound or create a template and that creates an inbound URL automatically. Okay? So what we see here is that we have this event where we basically have a URL that is created with resources universal event push, and then the name of the event. So that's the URL that your third party application can use in order to publish that event to us once we subscribe to it. Now also on this to do the authentication, we're then using the access token via the query parameter because in the specific applications I'm going to demo, they don't have the ability for me to configure ahead, it's just a URL, it's just an endpoint that they have. So we want to have authentication to that. So we'll set up a token for that application and we'll use that token in the URL and then we have control over it. We can revoke that at any time. We can set a limit on how long that list for. So we have some security around that, but it allows us to get in with some level of security there. So once I've created this event, I can create a monitor for this event. So basically the template definition, relatively straightforward. We're basically just giving it a name. The monitor definition is basically saying I'm monitoring for that event template and the trigger is saying that I'm going to run that and I'm going to trigger workload based on that firing. So when we get into looking at my S3 environment, I have a bucket that I want to monitor for. So any files that are created or updated in this bucket I want to trigger for. And in S3 that's configured through their properties through basically an event notification. So we start an event notification for the puts and posts, which is the updates and the create. Okay. And that event has a simple notification associated with it and I've created a subscription to that notification that is my end point. So this is going to push this to my controller here and all I've had to do is provide the URL for that event, so that's it. And I put my access token in there so that I have some security there. So if I then go and push something to that bucket there, we should see some workload come and hit the system. So I'm just going to do a little file transfer task and just send a file to that S3 bucket. Go ahead and launch that task. We see that that's running, we should see it go to success. And while we're waiting for that, oh we seen some workload trigger. But before we get into that, let's go back and look at that S S3 bucket and I'm going to go back one more and just refresh that bucket. And I have a file in that bucket. So that file has triggered my workflow. So it's triggered a workflow and I've put it on hold because otherwise the thing runs and we don't see what's going on in this case. So it's going to do a whole bunch of stuff. So I'm going to go ahead and deploy some resources in my Kubernetes deployment, download the file, do some other status checking, et cetera, et cetera. But basically that processing has been triggered just based on that file and I didn't have to do any polling to do that and it was relatively set up to there. So this will come up in a second. It takes a moment for that agent to register based on the environment it's in. So we should see that go to running in just a second and go through there, at least hopefully we should. I guess we can check the dashboard and see that I don't have agents running up. know what, this is always the trouble with demos is I have the environment that's running is not active. So we'll start that environment and then that work will go. Okay, let's see. All right, so now we've gone to the workload onto success. So there we go there, we've got some agent status, we've got some basically to stop that running so that we can go and have a look at what's going on because what I've done here is I've registered an agent here and this agent has registered through the Kubernetes cluster and he's registered with a specific business service so that all my security follows in there. So that was configured to do that with that transient agent and we'll see that if I'll let that go, that agent will be disabled there or decommissioned through the workflow and we're just deleting that deployment. Now we've done that, check the agent's status and we go ahead and see that that agent has gone down. So that's hooking together a number of the different things that we talked about there. But the key thing with the impound web hooks is that pretty much most of the modern applications you use now and all of the infrastructure components, all of the cloud vendors support web hooks. So there's really unlimited possibilities now for doing monitoring of any event, whether it's various applications or various infrastructure components. So we're back on the slides now and we can go through this. So we have that URL that gets generated when we create the event. And in this case I've got a sample in the slides of using a web hook from a Git repository so that basically all the pushes come in so that I can do some synchronizations with the GitHub tasks that we have moving stuff from the repository as I do commits to my main branch, do merges there, I can get that pulled into the control and have that automated. And of course we have then tasks available to do notifications through chat rooms like Slack or Teams and various others there so that we can integrate an approval process into that, that someone can validate that code and so on. So there's just an example of that. Here is where we're going to get that. And in terms of looking at the payload I get, and I didn't cover this with the with AWS example, is the various functions of variables that we have allow me to pull out information from that payload so I can pull out here who did the commit, I can pull out here the various information here of, in this case all of the files that were modified. So I have that information so that I can do that integration and there's other information from this payload that I can pull out and pass to that subsequent payload there. So for the Universal Templates themselves, a number of enhancements to that and we've seen that over time that what we're doing is enhancing big part of our strategy has been that particularly with the fact that now most people are going to already at running some kind of cloud, running hybrid environments. So the integrations they need is basically exploded. We get requests for new integrations almost daily. And our strategy we recognized several years ago was, look, in order for us to be a successful automation vendor, we need to be able to provide integrations for everything that you would need to automate because we can't automate if we can't integrate to it. So we built the integration platform to do that and that's been hugely successful. Our integration hub is very popular, very heavily used and got a lot of cool stuff in it, but what we're doing now is fine- tuning that. So things like the inbound integrations now is there with the monitoring we've got plans for some other exciting things coming on, but we're also enhancing this as we get through. So universal monitors can now pass variables to an already launched universal task publisher array field with predefined values that makes the forms easier to use for your users when you set these up. And also we are going through now adding integration to more and more of our own components. We've had the credential field so that you can leverage our credentials and of course now you can leverage those with third party provincial providers as well. We've added the SAP connection field type. We'll add the database connection and others as we go through. And basically we've also consolidated a status field for the extensions that we run. So one of the things we noticed is that is you write an extension in order in your activity, what you can do is you can publish, you've got the status of the task that we're running, which is the extension task, but you might auto also want to publish the status of the application event job, whatever it is that it's running. So what we found there was that unless everyone was very diligent and dedicated in which field they used, you couldn't really select a single field in the activity display that information. So what we've done is we provide a checkbox so you can provide an output field so that we get status on information that we will automatically map to a extension status field so that you could just have one field there that's in that list on the activity. So you can then see the status for all the different extensions regardless of how they coded that and how they set up the template there. We've also, for those that are developing and we use this heavily internally, we've been working on some toolkit updates for our developer stuff. So we've had a Python CLI that provides a lot of capabilities for making the development and testing of the extensions much, much easier, much quicker, much more seamless. And we've also then provided an extension for Microsoft's Visual Code Studio, which we use heavily internally. Now if you don't use that, if you use a different IDE, you've still got access to all the command lines through the Python tool, you can install that, you still have all those capabilities just for those that use the Visual Studio Code as we do. We've basically made that a lot more seamless. So some of the things we've added is being able to more sources for initializing the template to basically do a lot more debugging and launching without having a controller connection there. And also some helpers when you're starting to write the code. Some things that look at the template and give you the information you need as to if you're doing the dynamic commands, what commands have been defined in the template, if you're doing the dynamic choices, what choice have been defined in the template. So as you build those, it'll fill that information in for you or provide suggestions as to what's valued to go in those fields there. And also then a filtered list of the known variables as you're passing through the variables from the template and so on, things like that. So some cool stuff there to make that easier as we go through. Okay, so we've made some enhancements to the critical path. We've had a critical path function in the product for some time now. The original strategy was that we would look at a workflow and we would basically calculate the longest path through that workflow, which is the critical path, which is five in a lot of cases, but doesn't give the granularity of critical pathing that I think was needed in a lot of cases. So what we've done in terms of enhancing that is also now giving you the option to select your own critical endpoint or endpoints. There could be more than one critical path through any workflow, but basically this means that the endpoint is fixed that we're going to calculate critical path to. So you basically, what are your critical jobs, your critical tasks within that workflow? And it could be the last job in the workflow, it could be a job in the middle of the workflow, it could be several jobs in the middle of the workflow. That's not for us to decide, that's for you to decide. So all of that reporting that we have around the critical pathing in terms of understanding then if you get a failure, is it on a critical path to a critical job, you can now get all that in your reporting based on those jobs that really are the critical jobs in your environment. And you can define the critical endpoints in a number of ways. Through the workflow editor, it's a right click option, it's similar to doing the view edit run criteria. You now have a view edit for the critical endpoint and basically then you can set that up and you can have that defined based on all occurrences of that task. Same as we can do for the run criteria or specific occurrences of that task. 'Cause the task may be in a workflow more than once from that point view. And when you define those critical endpoints, you are able to view and manage those also through a tab in the workflow definition. So you'll see that there. So you have that capability to do that now. And the critical thing is highlighted and managed in the same way as it was if we were deciding if we were calculating the critical impact based on just the longest path through the workflow. Now we have a specific task here. So this is always going to be the end point regardless of whether this is actually going to take longer to run. But we can see that. So as we go forward there also in the workflows, we've provided edge conditions that you can now do comparisons on variables or functions or functions of variables and comparisons to a variable, to a function, a function to a variable or function to a function variable to a value. All of those things so that you can basically now have an extra way of making decisions within the workflow of how things run. One thing to bear in mind or to understand with this, and we are looking at how this works, but the way that the end processing for any task works is that the actions are fired off as a separate transaction. They don't have an impact on the status of the workflow. So when a workflow goes to success or when it's completed, it goes to success and there are a number of actions that you fired based on that success status, those actions are fired off in a separate transaction. So we have this issue with output because output does work in the same way. And when we added functionality to access a sibling task output, we added a checkbox to say wait for output. So we will look at something like that for the future for this, but just be aware that if you're setting a variable as a success action for a task that will not be considered when we get into the path processing for dependent tasks. Okay? It's not what it was initially designed for but we've recognized that that's a use case and we will come back and fix that, but that's just something to be aware of there. But it gives you extra capabilities in terms of being able to make decisions, not just based on the return code, the exit codes and so on. Okay. We're also now in the use variables and functions and set variable actions, which basically means is now when I do an action to a variable, I can have a variable name or a function name as part of the variable name. So what I'm using a template workflow or a template task, I can now have it depending on, let's say I have a workflow that runs for a number of different regions and the trigger pass is the region name in as a parameter. Well, I can now have that workflow setting global variables that are different for each region. So in this case I have a region name and that's what I'm going to set in there. So in this case what I'm doing is I'm just tracking a last run date and time for the various different regions, whether it's APAC, the European Union or the United States, I have that ability to do that. So as an example of that, and let's take off this all kind of make it clear if we get into that I have a number of global variables. Okay, so last run underscore AP, last run underscore EU, last one underscore NA. And I have a workflow that is going to use those variables. This is the one update region and this has an action in the workflow that says, hey, I'm going to set the last run for the region name to the specific date and I have a trigger here that passes the variable for the region in, and you can see I've got the variables displayed in the dashboard. So if I go ahead and run the EU one and trigger that to run now and just refresh that dashboard, we see that that's been updated. Okay, so only the Europe one was updated, it didn't have an impact on the others. Now I can run the same workflow with passing a different variable in and we can see that that variable gets updated. So this I think gives great power to the ability to have workflows that are reusable for example across regions or business units and so on from that capability. So good enhancement and extension to that capability. We've also allowed the ability to mutually exclude a task from itself and that's just a checkbox now on the task form. So you can basically say that it won't run against itself. Another instance of itself if it's already running. Okay, number of enhancements on the ZOS side, the mainframe side. So we've allowed temporary JCL library for temporary JCL changes. We've added the system infinity into the job card and the task for ZOS to populate that. We've made the timeout on JES output reconfigurable before we've allowed configurable space parameters for the temporary output data on ZOS that we use. And quite a big change. We've done a lot of work to the restart rerun, not only to allow it to be used externally, so now it be used in jobs that are not part, that are not triggered or run via a task from the controller. You could insert the UAC rerun step in your own jobs and use that capability to do the GDG cleanup capabilities. And as part of that we've enhanced the reporting on the GDG cleanup activities. And a number of enhancements on the platform support here. Okay? So for the Universal Agent side, the controller side we've updated, does it update to the GDG driver for the MySQL database? You'll see us do these from time to time as we're aware of new updates to that particularly where they're relevant. And for the Universal Agent, we've done a couple number of things. One, we've added proxy service support for the OMS connections. We've had some issues where that's been a requirement, particularly in the SaaS based cloud environments where they need to go through a proxy to leave the data center in order to communicate to the OMS from the agents. So we've added support for that. We've done updates to some of the libraries we've done if that's an ongoing thing as always, we always look at those libraries particularly looking at vulnerabilities and what updates we need to do. We've added support or we've done a certification for the Windows server 2022 and the ZOS 205 certifications been completed there. So we have that there out of the box going forward. So we have actually plenty of time for questions. So first questions we have, and if you got more questions sweet throw them in, was when we talked about the third party credential provider support and I mentioned that the password is called at execution time. It's saying does this mean it's not stored within UC? Okay. So the deal is no, it's not stored within UC, but we do cash it. Okay. So basically when you set up the credential, there is actually a test button so you can test that access to that credential works and that we can access the tokens that you specified that we need to get so that you are sure before you use it in production for any jobs that it actually works. However, when a job gets launched and executed we will look at whether we already have that cash. So in other words, has somebody already grabbed that password or that secret? If they have, depending on the provider and each one has a different mechanism for this and we are using their libraries within our tool, we're not doing APIs to call this, we've integrated their libraries, which is why it's a fixed list because yeah there's a little more function doorway their libraries into it, but more work from our side to do these integrations. So whatever their strategy is for cashing is we'll honor that. So yes, it will pull at execution time, it we will never store it but we may have it cashed in which case then it could be used by a subsequent job that comes along that wants the same credential, the same key value from there, it will use the cash version or if that cash has expired it will go ahead and pull a new one. So no, we do not store that at all. It's purely stored and managed within that third party provider. Will the validity of the personal token override the password reset requirements? So yes, it is different. So when you're creating, you'll have potentially set up a parameter to say how long a password is valid for the user. If you're using local passwords, you then have also the capability for the personal access tokens for the APIs to see each one to set its own expiration. So yes, they are different from that side. So you have the choice there. And the deal is that in most cases you would want to use for each application or external thing that's accessing the APIs, you'd want to generate a different personal access token and potentially have different expirations for it depending on its use. This allows you to be granular in terms of, well I've stopped using this or I don't want this integration to happen anymore. You can expire that token or revoke that token and it doesn't impact other applications that are using different tokens from that. Okay, so interesting. Well, we'll be able to have a value from date under version control for tasks so we can build modified tasks ahead of time and then schedule when the new version should become active without the manual intervention. Okay. So that's actually an interesting and good enhancement request. So obviously we have the ability for a new task within a workflow to have the restriction criteria to say hey, this is valid from, but we want the same thing for updates, not something that we consider but makes sense. But we are also looking at very heavily, I mentioned this in the opening keynote, what we talked about our plans and what was going on that we're looking at the jobs of code implementation and part of that could certainly well be that you would have stuff is pushed and we want to integrate it. That could be scheduled in terms of when we do those updates to do changes to pull that new version in. So there may be some capabilities there, but I'll make a note of that question, that's a very good enhancement request and certainly I think has some validity that we can have a version that's not published yet and have some way of doing that. We'll certainly look into that. Okay, I'm not sure if I fully understand this question but we'll give it a go and see if I can have a hack as I reread it through. So can you comment on the ability or lack thereof, automating legacy automation tools? Eji, you have legacy workflows running on premise via example here is Accessway Automator and you want to switch vendors, but during the transition phase you need a tool to still trigger those legacy workflows built in another workload application tool. Okay, well that capability I think is very much dependent on the capabilities of that legacy application tool. Does it give us a way of programmatically triggering and managing those and certainly if it has the right APIs or CLS or other ways of triggering their workflow or monitoring it to completion, there'd be no reason why something like an extension universal task and by couldn't be built to handle that. But that's going to be a different process for each one. It's certainly a consideration I think maybe for a discussion with our conversions team as to whether that's something that fits into how they do that. I'm not aware of any that we have out there at this point, but I could be wrong. But that's certainly something that we'll take on board and have some discussions about internally. Okay, so question here, a follow- up question for the cash password, how long does the cash password stay in uc? The cashing is dependent on the strategy for the credential provider. We don't control that. We basically cash based on their rules. So it's going to be different and I don't know, I don't really personally understand enough about each provider as to whether that's a configurable thing, but certainly we don't control the cashing. Okay. We basically will get it and we'll get usually an expiration with it and that will tell us how long we need to cash it for and then we basically discard it at that point. And then if when we got another task coming in, we kind of check that, do we have a cash version? Great use it. If not, we'll go and pull another one. But we don't store them unnecessarily on that side. But the cashing there is kind of helps with efficiency. We don't necessarily want to be doing that call to the external application. If I'm running a hundred jobs that need that same credential and they're all going to run within 30 seconds of each other, that would be a hundred calls we're here to get, achieve that with first job hits, it gets the credential, it's cashed, maybe five minutes later another job comes on and that cash has expired, but that's controlled by the third party credential provider. Okay. All right. We're still doing good for time so we've still got questions coming in so I'll keep going. Available restrictions, stress rules for an agent that wants to join an agent cluster based on certificates. Yes you can do that. That's currently supported. You can basically have certificate validation for the connection to the OMS, which effectively gives you the way to do that. So you can basically say that an agent can't connect to a controller unless he has a valid certificate that's been around for a little while. You should be able to find that somewhere in the documentation. If not, reach out to me, I've got some notes on that and configuration there. So that is currently already supported there to be able to basically have an agent be allowed to connect or not connect based on the fact that he has a valid certificate that you approve of. So can you trigger data pipelines or data loading jobs in third party data ingestion tools, EGHVR string sets or like replicate number their inventions. So the short answer to that is yes, those specific lists I'd have to look up and see. So this comes under the strategy or the category of integrations. So we have a number and I know we have a number of customers that are doing data pipeline type work across a number of different tools. And the nice thing about data pipelines is very heavily depending on integrations because there are so many tools out there and everyone seems to have a different mix of them, but I do know that we have some rights. So yes, if we don't have specific integrations that you need, reach out to us 'cause we're always looking at what integrations do we do next? What's popular out there, what do people need? Because we're in the business of enabling you to automate your business processes and your business processes require those integrations. So we have a vested interest in making sure that we get those out. So short answer is yes, that's part of what we can do in terms of building those workflows and managing that. Okay, so we have a question here and this is been a topic that I even had a discussion about this morning in another meeting. So there've been concerns voiced about the significant changes made to the seven two user interface and the need to retrain hundreds of users. Any thoughts about how to address these concerns And yes there are some. We've had lots of feedback, we've had lots of positive feedback and we've had some feedback with suggestions, things that maybe we missed or maybe we've changed and quite work out quite as well as we wanted. So we will see some further things coming. The major changes to the UI is really I guess is the concept of not having everything there for the user when he first logs on. He effectively builds his navigation, but everything is there, just a couple of different ways to get at it. So in my mind, and maybe this needs further discussion with the individual organizations that have issues with this is that the basic changes are relatively simple. I think one of the big things that's come up that we're still discussing a strategy around is the list detail view. And let me explain what I mean. Let's go back to sharing my screen, which is this guy here. So this was a top bottom view. So now we have a left right view. The advantage of this is that for certain task forms, and this isn't a good example, but if we get into here we go, something that's got a lot of data in it to just select a task is that we now have little less scrolling on this left- hand side. However, we do understand that means that the little less room for some of the options here that you may want to have across there. So you do have the ability to expand, but that is obviously a different click. So we are looking at having a user preferences to have that auto expand or remember the last state that it was in order to give you that view there. And then you can either if you want to still use the list there or can just obviously open the definition in its own window on your preference there from that side. So from the other side on the user interface. Now what I have from my perspective and I'm interested in feedback on this is I really only have the stuff that I use on a regular basis here, which makes navigating through this much, much easier things that I don't use less regularly I have access to here. So if I then want to get to task monitors, so I just want to go ahead and create a task monitor. I don't use that very often. I don't even have to open the task monitors this detail view, I can just go ahead and create a new one just by clicking on the plus. So I think we've provided some advantages and there is some adjustment we need to discuss. I think in terms of maybe providing maybe a quick starter video to go through the changes in philosophy because maybe we haven't explained that in enough detail from that point of view going forward. So I do say that organizers with large number of users are a little hesitant to push that in, but that's something reach out to us and I think we can engage with companies on an individual basis and address the issues and go through that and hopefully get to a status where everyone's comfortable with that. All right, so we've got a few questions. We've still got a little bit of time so we'll keep going through them. Are you considering allowing submitting an ad hoc SAP task with a different variant? Yes, we've got some discussions ongoing right now to enhancements to the SAP task. I believe that is part of what is being discussed. I don't have any dates there, but yes, we are considering enhancements there. Can we automate resource provisioning, spinning up PMs or waking up services your AWS and the answer is yes. So we already have a number of tasks within the integration hub to do some of that. If there are gaps, let us know. Again, we can build those integrations. Pretty much all of those infrastructure components provide everything we need to have those tasks available. So yes, that can be automated and as part of the demo I did when we looked at file coming in, I was automating, spinning up a Kubernetes deployment. So it's that kind of thing whether we could have made that an EC2 instance or something else quite easily just by selecting different tasks that to do that. So yes, that's part of the automation that we can do. It's really again down to the integrations. If you have infrastructure components that we don't already provide integrations for, let us know. We'll look at getting those into the queue. How do permissions work within inbound? Can you limit specific WebBook to a user stroke group? Well the web hook themselves or the is based on the setting up is based on the universal definition. So it's based on the security around that. That's effectively an administrative function. So I have to look at that in a little more detail to refresh my memory, but there is some limitations you can set on that in terms of how you do that. And obviously then the permissions you have coming in through the personal access token you use also can have an impact on whether it's allowed to fire that event or not. So yes, there are some limitations there as that can be set in terms of security there. When might we see versions on universal templates? The answer to that is no, I don't think we will see versions on universal templates and that's a deliberate design decision that was made very early on and there is an answer to this that kind of helps with features that we added in the seven two release that come there. The reason we don't allow versions on the templates is that there are changes you could make to a template that will invalidate the jobs that you have out there. So if you basically have a version of the template and you create jobs that use the capabilities, that template and then you revert back to a template that doesn't have those, you'll break your production and potentially cause all sorts of problems in the database. What do we do if you added a new field and you created tasks that use that field and then you revert back to the template? Are we supposed to go back and clean up the database with all those fields there? There's too many potential conflicts, however we do understand that guys may know what you're doing and may want to do that. So there's the ability to download the templates now that was introduced in seven two. So you can create an archive with the template and if you want to upload a new version, an old version of that template at your own risk so to speak, because obviously the certain changes you could break things, you have that capability and have had that capability since the seven two release. Okay. Basically it downloads the zip archive of the template when you do the export, the download of the template, the export of the template there. Okay. All right. Still got some questions coming in. We'll go to the wire because we've still got four minutes left. So some kind of training would definitely be helpful. Said wonder we cannot upgrade tomorrow without impacting users how to would be a great help. Okay, so yeah, reach out to your Stone branch representative there and engage with the services guys. They can help you with that. Okay, really no issue that, all right, so the flow of questions are slowed or the flow of questions are slowed. So I think we're at the end there now. Most people I think know how to reach out to me. Again, my contact information is fairly easy. It's first name dot last name stonebridge. com. So yeah, reach out to me if there are further questions, if we missed anything, if any questions come in after we wrap up here, we'll endeavor to get those answered as well. But I'd appreciate, I appreciate everyone's attention and thank you. Thank you, Colin, for going through all the new features in 7. 3.
Universal Automation Center 7.3 covers five areas: secrets management and security, integrations, critical path, workload automation, and platform support. This session works through each one with live demos.
Secrets management leads the release. Credentials now include a provider field, so instead of storing a password or token in the controller, you can pull it from a third-party secrets manager at execution time. Provider libraries are integrated directly, and caching follows each provider's own rules. Nothing is stored in UAC. Personal access tokens arrive alongside this, letting each user generate scoped tokens for API access and external applications. Pass them as a bearer token in an authorization header, or as a query parameter when the calling application cannot send headers. Tokens can be created, listed, and revoked through new API endpoints. They also solve a longstanding issue for single sign-on users, who can now authenticate to promotion targets using a token tied to their own synchronized ID. Email connections pick up OAuth 2 support. And the banner color is back, following feedback on the 7.2 interface.
Inbound webhooks are the headline integration feature. Most modern applications and cloud services publish webhooks, so you can subscribe instead of polling. Create a universal event template and UAC generates the endpoint URL for you. The remote system does the monitoring and pushes the payload, then you extract what you need from it and trigger workload. That matters for cost as much as convenience, since polling an S3 bucket every thirty seconds all year adds up in API charges. The demo triggers a full event-driven workflow from a single file landing in S3, including a transient Kubernetes agent that registers into a preassigned business service, runs its work, and decommissions itself.
Container and cluster security expands to match. Agents can be assigned business service membership at registration, clusters can require that membership to match, and you can cap how many agents join a cluster.
Universal Templates gain SAP connection fields, array fields with predefined values, a consolidated extension status field, and better variable passing. For anyone building integrations, there is a Python CLI and a Visual Studio Code extension that handle debugging and launching without a controller connection. Browse existing integrations in the Integration Hub.
Critical path calculation is no longer limited to the longest path through a workflow. Set your own critical endpoints, one or several, anywhere in the workflow. Critical path reporting then reflects the jobs that actually matter to you. Workflows also add edge conditions that compare variables and functions, variable names built from other variables or functions, and a checkbox to keep a task from running against another instance of itself.
On z/OS, 7.3 adds a temporary JCL library, system affinity in the job card, configurable JES output timeout and space parameters, and a restart and rerun step you can insert into jobs the controller did not launch, with improved GDG cleanup reporting. Platform updates include agent proxy support for OMS connections, an updated MySQL JDBC driver, and certification for Windows Server 2022 and z/OS 2.5.
Key Takeaways:
- Pull credentials from third-party secrets managers at execution time, with nothing stored in the controller
- Generate and revoke personal access tokens for API access, including SSO authentication to promotion targets
- Subscribe to inbound webhooks and trigger workload on events with no polling and no API polling costs
- Define your own critical path endpoints instead of relying on the longest calculated path
- Assign transient container agents to a business service at registration for predefined security