We have to set-up the local development integrated with SVN version control for wM 9.9. Till now we have been accessing the remotely hosted IS (maintained by other team) through designer in our Windows system, we have Linux license.
As POC we have done the below said things and have the concerns and questions around them:
Actions ?
We have Red Hat Linux (Red Hat Enterprise Linux Server release 6.4 (Santiago)) hosted on VMware (Workstation 12 Pro) player where we have installed the wM 9.9 Designer and integrated it with SVN as well. To install and run the designer we have installed Java (1.8.0_111)
We have exported all the packages of one of the business layer and we are able to Check-In and Check-Out our services.
As we have multiple business layers we would need more than one instances of IS for local development as all can’t take a same name as ‘Default’. We need to have the set-up in more than one system.
Further we are planning to create image files having separate set-ups of Local Development of several business layer. The individual image file would be one-stop-shop to access complete set-up provided to a developer.
Overall project is to further automate the build and deployment process linking Jenkins with SVN.
Questions ?
Could you please let us know the recommended versions of Red Hat Linux, VMware and Java for the above exercise?
We have given 70 GB disk space and 4 GB RAM for VMware, is it adequate?
Our system has 16 GB RAM and 450+ of free disk space.
linux\java version depend on webMethods version you are using.
4GB should be okay if you are running one instance of IS.
you can create multiple IS instance and change workspace in designer as needed. which ever layer you want to work with you can change workspace accordingly.
do you have different repo in SVN for diff layers?
So, coming to your point, we need to do local development and we realized when we are giving any name other than ‘default’ to the IS instance the features of local development (e.g. that small concentric circle) are not fully available. So that is spoiling our plan to name multiple instances for different layers. As we have to give the name while installing using the softwareAG installer.
Further, we have one repo location but there we can have different location of different layers.
For me IS is taking lot of time to start (around 40-45 minutes). Though I have increased the JAVA_MAX_MEM to 1024M the setenv.sh:
if [ “x$JAVA_MIN_MEM” = “x” ]; then
JAVA_MIN_MEM=256M
fi
if [ “x$JAVA_MAX_MEM” = “x” ]; then
JAVA_MAX_MEM=1024M
Let me know if I need to provide more information here.
My opinion, slowness of IS may not be by far related to local service development.
anyhow somewhere in 9x it was changed. now you no more change memory settings in setenv.sh. you need to make changes for memory in custom_wrapper.cnf file under profiles directory of IS.
and there could be multiple factor for IS to take up such long time. increase logging of your IS and see which steps are taking long time. that will put you on right track.
my apologies, i was not aware about limitation of instance name. in that case you can still have different workspace for different layers.
before installing multiple instances in your local workstation you may want to check with your Software AG account manager. it may not be allowed. you may be allowed to create only one instance.
my suggestion is to revisit your local service development approach. you can always use one single location for all your local development and then checkin\checkout to different svn repository.
----- architecture ----
May I suggest the following arrangement (IF you have the licenses):
one instance named “common” where you develop code to be shared on all environments (utilities, canonical schemas, common connections, etc);
one instance for each of the business layers;
one versioning repository (or branch) for each business layer and the common branch;
If the linking between each instance is to be done on UM, consider having one instance of UM per instance of IS, plus one interconnecting UM.
If you are linking the instances using other methods (WS, Remote Invoke, etc), consider using only logical names to designate the targets and creating an indirection mechanism to route the calls (using configurations, services, etc).
The only way for the common code to be installed on the other instances should be through deployment (you mentioned you are using Jenkins). Remember to ignore those in the business layers’ repository settings.
Consider having just one image prepared with the bare necessities of IS and UM (with all drivers and fixes and basic configurations) and let Jenkins deal with the specific configuration for each business layer (either deploying packages and configuration or setting up SVN and doing the corresponding checkout).
This way you only have to manage one physical image (just one place to update).
------ requirements ------
Please allow, at least, 1GB for each IS or UM instance (depending on the load of each layer).
Each individual IS instance has to be tuned in their /profile/IS_/configuration/custom_wrapper.conf and for UM in /UniversalMessaging/server//bin/nserverdaemon.conf
Command Central is helpful here too.
---- IS startup performance -----
Increase server logging on services.
Check connection problems
Verify the minimum packages dependencies are in place (packages with connections must depend on the respective driver adapters, packages with adapter services must depend on the packages with the connections, packages with triggers/notifications must depend on the packages where their respective documents are, etc.).
Check the startup services on each package.
Increase the number of threads, if necessary.
— forum policies —
Don’t ask too many questions in one topic, open more topics (you get more points too).
Having one single local IS for local service development with several logical servers defined, but all of them are mapped to the same pyhsical remote server alias.
Having different workspaces for each logical server defined.
Messaging bus can be a centralized one.
Regarding the repository (i.e. SVN) each workspace should have his own directory in the repository.
What makes me worrying a little bit in this scenario is how to handle common code which is the same on all instances but need to reside in each directory to be available in the workspaces. Eventually this can be handled by separating the common code in its own directory checking it out to each workspace.
with webMethods 9.9…the local version control setup only works with default Instance,
In 9.10 SAG allows the version control to work with any IS Instance in the Installtion(“9-10_webMethods_Release_Notes.pdf-page 8”)
If you want to continue with 9.9. here are your options
1.Create a golden VM image with Local Workstation and svn connectivity setup.Keep spinning up and tearing down VMs based on number of Developers
2.Create a Local Designer workstation Template in Command central and keep deploying and removing from Developer vms as per requirement
3.Create a container of the Setup and run and remove as required
With 9.10 the above options will also work in addition to the possibiltty of having one development installtion and multiple developers developing locally as required.The flip side is that you will run out of processing power and space soon.Just spin up another instance using the above method and continue
Regarding your auto -build setup…That should be setup separately …I installed Command Central,Deployer,and Asset Build Environment,Jenkins and Ant separately and have it hooked up to SVN to do its thing.
webM recommends installing the Command Central,Deployer,and Asset Build Environment separately as they are common across installations.
Hope this helps…Experts please comment with any point.