 Hi, I'm Dave Seltzer with BMC Software, and today I'm going to show a custom application we built using Innovation Suite. This large telco wanted a custom application to replace a manual process they had. They had network users who needed to request firewall changes, network engineers to stage them and prepare them, change managers to approve them, and finally people to implement the changes. The whole process looked something like this, pretty complicated when we sketched it out, but we wanted to create a very specific small application to handle just these use cases. So when Jim logs in, he's actually directed here probably from Digital Workplace to make a request. There's a template that allows him to choose the type of project for the firewall changes, and based on this template, service items will be created accordingly. He's chosen a pretty simple template in this case. Now the network engineer is notified and logs in. She can see that there's some notifications here about objects being created. So she looks at the staging area and sees that there is a new service request. It needs to be assigned to a staging person and an implementation person. You can see that the template caused the individual service items, which are IP, address changes, and firewall access changes, and firewall rule changes. These were all generated by the template. Now she can go in and start to stage it. She would start by identifying IP address changes that are going to happen. This is a fairly simple object. As she starts to do this, she can invoke an integration to an IP address management system to automatically generate a free IP address. Also some custom code is used to validate it. After doing this a few times, there's a database of IP addresses available to go in and do the more complex change, which is a firewall rule change. Before this application was built, Jane had to do a swivel chair operation to identify where the firewalls are between any two endpoints. We automate this in this application. The endpoints and the firewall are automatically identified, and now templates generate individual rule changes for the firewall. All this is data-driven and can be set by configurations. We're only going to create one rule here, but this could replace large spreadsheets with a lot of different manual processes for approving the spreadsheets and analyzing them. Once it's ready to be approved, it's submitted for approval, and Ajay, who is our business analyst, would log into the same application and be able to review a complete set of changes before allowing them to be implemented. So we implemented a custom report using HTML and JavaScript that allows you to create a printable view as well as export the data in a CSV file so it can be brought up in Excel. Since the main purpose of this POC was to show how the complex task of staging could be done by a custom app, we didn't spend a lot of time creating workflows for implementation of the firewall rule changes. We just implemented an example ticketing system. In reality, this would integrate back to an industrial-strength ticketing solution like Remedy, ITSM, or ... So that's the application. It has quite a few different types of records and associations and workflows. Let's take a look at how it was built. In the innovation studio, you can see there are quite a few records here. The full data model looks something like this. The primary object is a request. Also, there are quite a few views involved in this. You could see them when we ran the application. Here's what the design time view of the first few we looked at seems like in the innovation studio. Quite a few processes as well. This is where all business logic happens. The most important one is the lifecycle of a request. In this case, you can see that there's quite a few capabilities in the palette of the process designer. Most of these steps either involve waiting for our request to change its state or to notify someone or to handle a cancellation of a request at different times. There's also features in the process where it will wait a certain amount of time, automatically change its state or notify someone. Also it can loop through associated items and take actions based on them. In fact, it delegates the generation of associated support items to a child process that's maintained outside and could even be customized without having to customize the primary process. This is a really important feature in innovation suite and process designer. You can separate out those business processes owned by one entity from those that plug in and it can be customized by another entity, which we call tailoring. You can also create administrative interfaces. These show up in the settings console just like the platform settings. This is where the data can be managed that runs the application so administrators can have their own interfaces to set up the data. When you did, you write some custom code for this application. You saw examples from the trace routing and then the IP address generation and the IP address validation. So what do we want to show with this particular POC? Obviously, we want to show how you could improve productivity using this tool at a much lower cost. Catalogs to choose, different types of requests that behave differently, integrating systems together so you don't have to swivel chair between different systems. Custom workflows to replace manual spreadsheets and capturing complex tribal knowledge and templates. Development is much more rapid. We have an MVC model that you can use to create persona based experiences. Process-centric design minimizes the coding and make it repeatable and extensible with a data model. The amazing thing about this is that it didn't take very long to build a few weeks basically. Most of the application is codeless. There were some bits of code that were added for some key integration and other capabilities, which can often be done codelessly as well. Thanks for watching. Please check developer.bmc.com for more information.