One of my customer asked me the following question:
“I have my own logging event system and I would like that all log files information of the WebSphere Enterprise Application environment are copied to my logging event system. I don’t want to recreate the full WebApp pattern-type just to add a new functionality. So, how can I leverage the existing WebApp pattern-type and add in it just the functionality I need?”
The answer is very simple: Extend the WebApp pattern-type by adding a plugin which fulfill your requirements.
Extending a pattern-type is very easy, what you have to remember is that a pattern-type is composed of a pattern-type definition and a number of plugins attached to it. The pattern-type definition specify its version, name, description… and each plugins attached to it specify their relationship with the pattern-type definition via few lines in their config.json file.
When you look at the webapp pattern-type, you will find that its name is “webapp” and the current version is “2.0”, so all you have to do is to create a new plugin which is linked to this pattern-type.
Let’s take the following example, I have the provided WebApp pattern-type and I would like to add one component in this pattern type. So, I create a new plugin called “plugin.com.itdove.pext” and specify that this plugin must be attached to the “webapp” pattern-type version “2.0”.
Remember you can use the Eclipse Plugin to create new Virtual Application Pattern plugin: Please read this article.
Application Model (metadata.json)
So, let’s mention that this plugin will be associate with the webapp version 2.0. This is done by specifying in the patterntypes section, the primary pattern-type.
BTW: If you want that the plugin is available for all pattern-type, such as the plugin-debug, just remove the primary section and add “secondary” : { “*”:”*” }. You can find more information in the “Plugin_Developer_Guide.pdf” available in the docs directory of the PDK.
{
"name": "plugin.com.itdove.pext",
"version": "1.0.0.0",
"patterntypes": {
"primary": {
"webapp": "2.0"
}
},
"packages": {
"PLUGIN.COM.ITDOVE.PEXT": [
]
},
"parms": {
}
}
Once it is done, you can continue to develop your plugin by adding components, links, policies…
Here I added in the metadata.json a new components which represent my LogManager component which required a logDirectory string parameter.
[
{
"id": "LogManager",
"type": "component",
"label": "Log Manager",
"description": "Capture Logs",
"category": "MyOwnExtension",
"attributes": [
{
"id": "logDirectory",
"type": "string",
"required": true,
"label": "Log Directory",
"description": "The directory where log will be kept"
}
]
}
]
I can upload this new plugin in my SmartCloud Application Workload Services environment and I can see I have a new component in the ‘webapp’ pattern-type.
and when we drag and drop it, we can see the logDirectory parameter.
Scripts
You can also launch scripts on the Enterprise-Application to setup of example a messaging connection toward the LogManager; for that you will have to create a part, define the part in the config.json for the Enterprise-Application.
In fact you can get inspired by the Master/Slave example to implement it.
You will have to find the role you would like to extend and use that role name in your configuration. You can find the role by opening the Storehouse Browzer and navigate to the plugin you would like to extend and look at the configuration to find out the role name.
For example:
and the changed.py script is:
import logging
import maestro
import sys
logger = logging.getLogger("changed.py")
logger.debug("Start LogManagerLink config");
deps = maestro.deps
added = maestro.added
myrole = added[0]
HOST = deps[myrole]['LogManager_IP'];
logger = logging.getLogger("configure.py")
logger.debug("Configure MasterSlaveLink with LogManagerIP=%s" % HOST);
utilpath = maestro.node['scriptdir'] + '/WAS/start_server_util'
if not utilpath in sys.path:
sys.path.append(utilpath)
import startserverUtil
# Let WAS role see if it needs to changes it's status
startserverUtil.process_dependencies()
You can see that some extra-lines has to be added (from ‘utilpath’ to the end) to extend the WAS and these are specific for the WebApp pattern.
Conclusion:
You can easily extend any pattern-type to fulfill you own requirement.
References
– Pattern-type (Part 7): Scaling in/out based on OS metrics with SmartCloud Application Services
– Pattern-type (Part 6): How to add operation with SmartCloud Application Services