Part 1: https://community.hortonworks.com/articles/82964/getting-started-with-apache-ambari-workflow-design.html Part 2: https://community.hortonworks.com/articles/82967/apache-ambari-workflow-designer-view-for-apache-oo.html Part 3: https://community.hortonworks.com/articles/82988/apache-ambari-workflow-designer-view-for-apache-oo-1.html Part 4: https://community.hortonworks.com/articles/83051/apache-ambari-workflow-designer-view-for-apache-oo-2.html Part 5: https://community.hortonworks.com/articles/83361/apache-ambari-workflow-manager-view-for-apache-ooz.html Part 6: https://community.hortonworks.com/articles/83787/apache-ambari-workflow-manager-view-for-apache-ooz-1.html Part 7: https://community.hortonworks.com/articles/84071/apache-ambari-workflow-manager-view-for-apache-ooz-2.html Part 8: https://community.hortonworks.com/articles/84394/apache-ambari-workflow-manager-view-for-apache-ooz-3.html Part 9: https://community.hortonworks.com/articles/85091/apache-ambari-workflow-manager-view-for-apache-ooz-4.html Part 10: https://community.hortonworks.com/articles/85354/apache-ambari-workflow-manager-view-for-apache-ooz-5.html Part 12: https://community.hortonworks.com/articles/131389/apache-ambari-workflow-manager-view-for-apache-ooz-7.html In the last tutorial I created a coordinator called part-10-coord. I'm going to use it in this tutorial to create a bundle. I'm personally new to bundles and only discovered them reviewing WFM. You can learn more about bundles here https://oozie.apache.org/docs/4.2.0/BundleFunctionalSpec.html Bundles are designed to make working with coordinators easier and managing coordinators on more holistic level. Bundle is a higher-level oozie abstraction that will batch a set of coordinator applications. The user will be able to start/stop/suspend/resume/rerun in the bundle level resulting a better and easy operational control. More specifically, the oozie Bundle system allows the user to define and execute a bunch of coordinator applications often called a data pipeline. There is no explicit dependency among the coordinator applications in a bundle. However, a user could use the data dependency of coordinator applications to create an implicit data application pipeline. Let's go to the top right hand corner and click on create, this time selecting bundle as choice. You're now prompted to enter coordinator information. Click on Add Coordinator button and fill out with existing coordinator information giving the full path of the coordinator XML file. If you provide a full path to the coordinator XML, coordinator name will be populated on its own. If your data pipeline consists of many coordinators, you can chain them here by adding more coordinators and their paths. Since my pipeline consists of only one coordinator, (yes not really useful, though I can see how it can be useful when you have multiple), I'm going to click on green Add button to finish. Last thing left to do is enter kick off time. It expects a date, if none given, it will default to NOW, which means it will kick off immediately once submitted. Bundle Application Definition A bundle definition is defined in XML by a name, controls and one or more coordinator application specifications: name: The name for the bundle job. * controls: The control specification for the bundle. kick-off-time: It defines when the bundle job should start and submit the coordinator applications. This field is optional and the default is NOW that means the job should start right-a-way. coordinator: Coordinator application specification. There should be at least one coordinator application in any bundle. name: Name of the coordinator application. It can be used for referring this application through bundle to control such as kill, suspend, rerun. app-path: Path of the coordinator application definition in hdfs. This is a mandatory element. configuration: A hadoop like configuration to parameterize corresponding coordinator application. This is optional. Finally, I'm going to rename the bundle workflow to part-10-bundle and submit it, notice I saved it to /user/centos/part-10 along with existing workflow called part-10 and coordinator called part-10-coord. All three XML files will be in the part-10 directory for organization purposes, though not required. Same as with workflows and coordinators, I can see my bundles run on the Dashboard. The configuration options change a bit and I no longer see an action tab, I see a coordinator tab. It also shows all my running coordinators that belong to the bundle. The definition tab shows all required properties for bundle to run. WFM makes it easy to fill out the properties and you're no longer required to maintain a job.properties file. Last thing I want to do is show you XML generated for this bundle. This tutorial just goes to show you how easy it is to start learning Oozie nomenclature, before my experience with WFM, I did not know how to work with bundles, decision nodes, SLA features, etc. WFM makes working with Oozie more approachable. Until next time! ... View more

Part 1: https://community.hortonworks.com/articles/82964/getting-started-with-apache-ambari-workflow-design.html Part 2: https://community.hortonworks.com/articles/82967/apache-ambari-workflow-designer-view-for-apache-oo.html Part 3: https://community.hortonworks.com/articles/82988/apache-ambari-workflow-designer-view-for-apache-oo-1.html Part 4: https://community.hortonworks.com/articles/83051/apache-ambari-workflow-designer-view-for-apache-oo-2.html Part 5: https://community.hortonworks.com/articles/83361/apache-ambari-workflow-manager-view-for-apache-ooz.html Part 6: https://community.hortonworks.com/articles/83787/apache-ambari-workflow-manager-view-for-apache-ooz-1.html Part 7: https://community.hortonworks.com/articles/84071/apache-ambari-workflow-manager-view-for-apache-ooz-2.html Part 8: https://community.hortonworks.com/articles/84394/apache-ambari-workflow-manager-view-for-apache-ooz-3.html Part 9: https://community.hortonworks.com/articles/85091/apache-ambari-workflow-manager-view-for-apache-ooz-4.html Part 11: https://community.hortonworks.com/articles/85361/apache-ambari-workflow-manager-view-for-apache-ooz-6.html Part 12: https://community.hortonworks.com/articles/131389/apache-ambari-workflow-manager-view-for-apache-ooz-7.html In this tutorial, I will cover how to create Oozie coordinators via Workflow Manager View. I'm also going to leverage Publish/Import Asset functionality demonstrated in my last tutorial only now using local database rather than HDFS. We're going to publish the two actions nodes from part 9 (shell action doing echo and email action) using the next to last icon when you click on the action node. So just like I did in part 9 to publish an asset to HDFS, same steps except there's no HDFS path. You're greeted with dialog to give asset a name and description. I already published shell action to assets database in the same manner. I'd like to glance at what assets I have in my local Ambari Views instance. To do that, I'm going to click on manage assets button in the top right hand corner. You're going to see a list of any saved assets so far. In the same manner, you can delete assets by hitting red trash icon to the right of them. Asset manager also allows you to search through all saved assets. Keep in mind that local asset database is exactly that, local, it is not being shared across instances of Ambai Views nodes. For that, please use publish/import from HDFS functionality just like in part 9. We're ready to tie it all together, we're going to create a new workflow, name it part-10, then begin to add new nodes, though now instead of adding pre-existing nodes, we're going to click on import asset You'll get a pop-up to select an asset from asset manager. Click on it and hit import. Now we're ready to import 2nd asset Select the asset and import it. Your workflow should look like so I gave the action nodes more meaningful names. We pretty much built this wf from the wf in part 9 using publish/import assets. We can now submit the job. (The path mistakenly points to /user/centos/email, I then submitted this workflow and saved path to /user/centos/part-10). Great, now we know it works, we're ready to create a coordinator workflow. On the WFM page, in the right top hand corner, find create button and select coordinator. You'll be prompted to fill out the details. This beats working with XML as all I need to do is fill out 5 fields and I have a working coordinator for an existing workflow, by clicking the button next to the browse, you get an option to create a brand new workflow, since we already have one, we're going to enter the path of the existing one. I'm ready to submit the coordinator. I prefer to save coordinator and workflow in the same directory, though my screenshots do not show that, I chose /user/centos/part-10 as the HDFS path for both workflow and coordinator in my recent work. This is what my directory looks like hdfs dfs -ls part-10 Found 2 items -rw-r--r-- 3 centos hdfs 364 2017-02-23 17:58 part-10/coordinator.xml -rw-r--r-- 3 centos hdfs 971 2017-02-23 17:09 part-10/workflow.xml Let's preview coordinator XML. Ignore the app-path in my XML, I have two one in /user/centos/email and another one in /user/centos/part-10. I grabbed the wrong screenshot :). Let's look at our coordinator running and this will allow me to demonstrate some more cool features of WFM like chaining of search tags. Let's click on dashboard button and see our workflow in action, notice the clock icon to the left of it to identify it as part of a coordinator. This still shows workflows, if you click on the left of the page where workflow drop down is and select coordinator instead, you can see only coordinators. It makes it easy to filter out coordinators from workflows and as you see soon bundles by toggling the drop down to select the type of job you're looking for. Here's an example of what a coordinator triggered every 5min will do to your dashboard. Another cool feature in the dashboard is multi-tag search. In Oozie UI, you can click on name and it will sort ASC/DESC, here we can filter out using pre-defined tags instead to narrow down output to what's relevant. Notice I added name filter. What if I also want to filter by status:SUCCEEDED and not just name of wf? I can also add more tags, now I want to also filter out only running workflows. Now I want to also filter by user name The other available options are below Finally, since my coordinator is configured to execute a workflow called part-10 every 5min, I'm getting a lot of emails every time it runs and succeeds. I want to kill the coordinator. I can do it directly from the dashboard. To the right of the running coordinator, I have an option to kill highlighted in red, click that. once clicked, coordinator goes into Killed stated. ... View more