If you are interested in Rational Automation Framework, DevOps or just trying to stay up on what is happening in Rational. Please follow the @RAF_WebSphere twitter. Thanks!!!
It's Friday afternoon as your fingers slice across the keyboard and your mouse chirps click by click. You sit anxiously awaiting an email. DING! You race to open it and scribble down your thoughts before they magically disappear. The editor prompts “Format may not be correct”. To your surprise, It's all jumbled. You go strait to google and ten editors later, success. In many instances it is easier to download on autopilot while searching Facebook and monitoring your tweets than to do any actual reading of the documentation. We just keep downloading something different until we find what we need with the expectation that is exists. After all, you can stroll into Best Buy, buy a phone, link it to your tv and stream music videos in HD with surround sound. When approaching RAF I let my expectations shape my approach. It was a horrible idea and hopefully this will save you from going down the same path.
RAF leverages Rational Build Forge, agentless connectivity (RXA), SUDO permissions, ANT, Jython, wsadmin and a base root of automation plans to Administrate WebSphere with over a thousand actions. Why not give it the ol' college try. Why not jump in and learn trial by error? I will tell you just why not to do that.
When I dove right into Rational Automation Framework some time ago. I had no plan or direction. I was like Maverick in top gun. Needless to say I found an action called install was and flew with it. Hours later with a healthy amount of frustration. When finally completed. I was excited and disappointed. I had a poor understanding of the product. It seemed every time an install failed, I was just as baffled as the first time. Chasing down errors with no idea what I was doing and hoping for the best until I was successful again. Armed with very little knowledge. I new that an action performs a task. The action came with the install of RAF. So why wouldn't it work? When the action failed, I expected it was something I did. Expecting somehow RAF new what I was trying to do. Once I stopped, removed all expectations of any kind, and approached my install with a blank slate. I started making progress. Expectations are a state of mind, seemingly simplistic but often almost always over looked.
When approaching the application without expectations. I was forced to break down the process into many different sections. As if I were developing a product to install WAS myself. I would need to break an automation plan into Projects, Libraries, Steps, and properties. With documentation in hand, I learned a project is a definition of work made up of steps. Steps control the projects behavior through properties. I would have viewed the Project, and noticed that it had an in-line. An in-line is a Library that consists of a set of steps that do not change. These steps can be called from other projects or libraries by setting it as an inline. I navigated to the library page where I saw that there are multiple types of steps. Some steps have conditions, others have loops. I noticed that the install node step was conditional. It iterated through the number of nodes I wanted to install. I also noticed how it assumed I was doing this on two separate machines. two nodes two machines. I also noticed the property called “Thread”. I am installing two nodes on one machine at the same time. RAF threads these steps making it's own assumption that you are using two or more target systems. I would have fixed this first.. Not expecting RAF to know I only had one machine without telling it first.
Lets say I found an action was_common_configure_security_federated to import AD users. I ran this action against my test environment and it failed. It didn't just fail, But locked out all the users from being able to log in. Instead of plugging that action in and expecting it to work, I should have removed all expectations and broken it down.
What is an action? Is there a way to gain additional information on an action? If I had searched for “documentation on actions” in the IBM info center. I would have found RAFW command Syntax. This would have lead me to rafw.sh/bat <scope> -p <actionName>. This command finds the xml associated with this action and tells the location of that xml file. I would have also found that I can list all the available actions at a particular scope using rafw.sh/bat <scope> -l. sifting through the XML I can see that this action calls a script. Again, telling me the name and location of the script in question. I open the Jython script and notice it's an AdminTask. AdminTask commands are not recommended to run on an active server. If a conflicting configuration is saved, it can corrupt the server. This is probably what happened. By using the second command (-l) I may have found that was_common_configure_security_all was a better action to use. It is a composite action. That runs several actions underneath it to gain all the security data. Instead of running these steps threaded one by one, opening a new JVM for each one and causing slower performance. I could have ran this one composite action in long running wsadmin and opened one JVM to run all the associated action. Although, just because long running wsadmin is specified by -useLongRunning does not mean that it will work out of the box. Get out of here expectations!
By removing all expectations and clearing the slate. You are forced to use targeted discovery in order to break down the process, target each section of the process and understand it's purpose in relation to the bigger picture. You will be much more successful following this type of outline when dealing with RAF. Even the easiest thing such as starting or stopping a JVM can get incredibly complex in the event it fails. What if your server was installed as a windows service? You shut it down, but now you can't start it. You have no control over the associated servers. Remove expectations and use targeted discovery and you will be fine. Happy Automating.