Live from Software AG Processworld 2012: Day 1

The day started with general keynotes from the CEO and CTO of Software AG. During these keynotes the so called “4 forces, shaping the future of IT” of Processworld 2012 were introduced:

• Big Data    
• Social/Collaboration 
• Cloud 
• Mobile

All of these 4 forces are integrated in the new ARIS 9.0 and webMethods 9.0 releases by a number of new products. The one that were addressed today are the following:

• ARIS connect: a complete new product focusing on the social and collaboration part. It is an addition to the existing ARIS product line. During the session a demo has been given showing how multiple persons can collaborate in an ARIS process. A person can invite someone else to collaborate in an ARIS process, meaning the person can put comments, can view the part he or she is responsible for and so on.
  At this moment there are different ARIS products, each of them having their own version. With ARIS 9.0 there will be only one ARIS client with version number 9.0 and extension packs in case specific features are wanted. 
• webMethods pulse: is focusing on the social and mobile part. This event-driven solution is based on the webMethods ESB and allows us to subscribe to business events and to get warned in real time on our mobile phone or tablet. 
• Cloud streams: is responsible for cloud integration. While the webMethods SalesForce adapter is only focusing on integration with SalesForce, cloud streams comes out of the box with a lot more SAAS connectors (salesforce, google, …). It has also advanced security, traffic analysis and SAAS governance on board.
  I discussed the comparison of the salesforce adapter with the cloudstream solution with a software AG expert at the cloud booth. The main advantage of cloudstreams is that it delivers a shorter time to market compared to the adapter. With cloudstreams they provide a framework that can easily adopt a new version of the API that is availaible in the cloud (cfr the updates of the salesforce partner WSDL).
  Cloudstreams can be installed as an integration server package. 
• Nirvana messaging: A java based messaging system for webMethods with the same functions as the broker + additional API's for javascript, iOS, android, ... Tests have shown that the nirvana messaging solution is up to 10 times faster than the broker (including guaranteed delivery). So there is a chance that it will replace the broker in a far future.
• Command Central allows us to administer almost all webMethods components via one central GUI. It allows administrators to: 
• Perform landscape management by stopping or starting, monitoring, perform license management, basic alerting of webmethods components. 
• Manage fixes by comparing fixes across servers and install fixes on the servers. 
• Perform central configuration across products, compare the configuration and provide access to the legacy UI. 
At this moment they are still working at the product, since the central configuration is still a work in progress. Although the GUI is one way to access command central, it also can be accessed via command line, service API and even a mobile API. For the command line you can give a command to perform a specific operation or XML scripts can be used to apply changes using the command line.

Command central provides a standard API, independent of the underlying runtime. This means you can configure for instance a JNDI connection in CC in one way, whether it needs to be applied on integration server of MWS.
In the future it also will be possible to install products using CC.
On top is this all you can define templates, manage substitution variables and apply these templates to target servers.  

Author: Dimitri Van Kerckhoven

Crossvista: ALM and concurrent development for webmethods (part 2)

Components

CrossVista as a whole contains the following parts:

• CVCM package: the core TEAM server product 
• CVCM agents: packages that need to be installed on every integration server TEAM needs to connect to. Will be done automatically in the background. 
• TeamVCS package: package for concurrent development, to be installed on every development integration server 
• Team API: API to access the team services 
• CvTunneler.jar: tunneling for webMethods reverse proxy 
• TeamVCS plugin for eclipse (webMethods Designer)

 

System Requirements

CrossVista can be run on the latest versions of the webMethods platform: 6.5, 7.1, 8.0 and 8.2. Many version control systems are supported out of the box: CVS, SubVersion, VSS, ClearCase, TFS, but you need to mention the version! Only a limited number of versions are supported and not following these requirements will make CrossVista possibly not work. Since the CVCM and TeamVCS packages contain java server pages, the WmTomcat package needs to be enabled on every integration server containing one of these packages.

Installation

Installation of CrossVista is very straightforward since the core products are nothing more than just packages that need to be deployed on an integration server:

• Install the CVCM package on one and just only integration server. This integration server will become the TEAM server. There are no recommendations whether this can be installed on an existing integration server, hosting other packages or whether a separate integration server needs to be taken for a good operation. 
• Install the TeamVCS package on every integration server that can be categorized as development machine. 
• Install the TeamVCS plugin for webMethods Designer in case you want to develop BPM or CAF projects. 
• Assign users to the TeamAdministrators and TeamUsers groups and ACLs in integration server. These groups and ACLs will be created when you install the CVCM package. 
• Give non administrators that need to access Team server or TeamVCS access to WmTomcat. By default only Administrators can access the WmTomcat package functionality. You can add them in the web.xml file under web/WEB-INF of the WmTomcat package.

 

CrossVista Terminology and workflow

Two import names need to be kept in mind before you start working with CrossVista:

• A TEAM project: a definition of all the constituents 
• A release: an instance of a project

As you can see you can make the link with webMethods deployer naming. You define a deployer project, where each project can have multiple builds.

In order to work correctly with CrossVista, the following workflow needs to be followed:

• Define a new TEAM project. In this project you define the constituents that form the project (packages, configuration files, sql files, …) 
• Upload the project in the version control system. Here a new release will be created and the release will be stored in the development repo 
• Promote the project. Promotion means moving the release from one repo to another using promotion rules. In these promotion rules you change the configuration and target servers to be conform to the new environment. Promotion does not mean you deploy the release! 
• Deploy the project. Here you select the release from the repo that corresponds to the physical environment on which the release will be deployed. 
• Analyze the project

 

Features overview and their strengths and weaknesses

• Automated release cleanup. This sounds promising, but the feature only allows cleanup after x days. This means that when you don’t make any new release during x days, all your releases will be deleted 
• One repo per environment. A good feature to keep separate releases per environment. You always need to be aware in which you are working. This feature is prone to mistakes. 
• Almost everything can be part of a release: 
• IS services 
•  Extended settings 
•  Adapter connections 
•  Schedulers 
•  Users, Groups, ACLs 
•  Broker clients 
•  TN, MWS, BPM resources 

• Dependency definition between projects. Very useful feature. You can define the type of dependency: latest release, a specific release or a range of releases. Team server detects the missing release and will automatically add the missing release. 
• Visual diff between releases. Probably the best feature in Team server. It allows you to compare two different releases visually for flow services, document types, java services and flat files. It also allows you to make a live compare between a release and live integration servers.  
• Create a new release based on an existing one. You can make a new release, which is a subset of an existing release or you can merge different releases. This seems to be a dangerous feature, because you need to be aware very well of what you are doing. A mistake can be made quickly. 
• Site definition and check whether sites are in sync. You can group multiple integration servers in a site and check whether this site is in sync with another one. By default integration server also provides this feature when they are running in a cluster. 
• Built in scheduled tasks. This feature doesn’t seem to be very useful. You can create scheduled tasks for automated upload, deploy, promotion, etc. The question is why would you do that? The TEAM server solution seems too complex to me to automate such things. 
• Easy to keep track of changes since release notes can be added 
• Out of the box support for many version control systems, but you need to be aware of the version you are working with. 
• Automated creation of revisions, triggered by the lock/unlock operation in developer. Doesn’t seem to be very useful since a good practice is to make a full release when you are finished. Can act as a backup mechanism. 
• Concurrent development. Nice feature in case you need it, but I haven’t found an environment so far where this feature has been missing. 
• Support for both shared development (one integration server) and distributed development. The TeamVCS feature seems to be very useful in case of distributed development, but not necessary when development is being done on one machine. In that case you can start making releases directly from within team server when development has been finished.

Author: Dimitri