integration & source control · pdf filecontrol software, specifically how to seamlessly...

14
Providing IT Solutions for the Integration Community INTEGRATION & SOURCE CONTROL MANAGEMENT Implementing A Source Control and Version Control Methodology with webMethods Enterprise Server Products Authored by: Jordan Braunstein Visual Integrator Consulting, LLC [email protected] www.visualintegrator.com Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 1

Upload: dangdieu

Post on 21-Mar-2018

219 views

Category:

Documents


5 download

TRANSCRIPT

Page 1: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

= Providing IT Solutions for the Integration Community

INTEGRATION & SOURCE CONTROL MANAGEMENT

Implementing A Source Control and Version Control Methodology with webMethods Enterprise Server Products Authored by: Jordan Braunstein Visual Integrator Consulting, LLC [email protected] www.visualintegrator.com

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 1

Page 2: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 2

Introduction: Architecting an integration system provides numerous methological challenges, especially when dealing with the distributed nature of objects in the integration system. On top of the normal implementation concerns, is the fact that many integration vendors have yet to provide the full spectrum of utilities to facilitate a standard implementation methodology. This article addresses how to assemble integration objects into Source Control software, specifically how to seamlessly “integrate” webMethods-specific objects with a 3rd-party Source Control Management (SCM) tool. More specifically, this article explains Source Control activities within the webMethods Enterprise Server product suite, including Enterprise Server (ES), Enterprise Integrator, Adapter Manager or Adapter Configuration tools (ADK), and webMethods command line tools. The article provides processes for overcoming the “out of the box” SCM difficulties and recommends Best Practices for the integration team to use throughout the project’s lifecycle. WebMethods Integration Server (IS) is not addressed in this article for good reason—the product has more features that allow it to plug-in more harmoniously with an SCM tool (Note: Integration Server does have its own proprietary difficulties when dealing with SCM tools). This article also assumes the reader has a baseline knowledge of the objects represented in the Enterprise Server software suite, how the webMethods Enterprise Server product operates, and an understanding of the client tools provided with Enterprise Server. Due to the difficulties involved with integrating a SCM, it is necessary to construct enforceable guidelines for the integration team to base their implementation on. The article provides many of those guidelines, although not a complete guideline for one’s particular integration environment. Managed Objects Enterprise Server consists of multiple “Development Level” and “Infrastructure Level” objects throughout its distributed system. Development Level objects are defined as objects created by a developer to address logic required within the integration system. These objects are centered on custom code to address data transformation, data validation, and business logic. Infrastructure Level objects are defined as core objects required for the integration architecture—Infrastructure Level objects must be defined before a developer can begin creating the Development Level objects. Infrastructure objects consist of Brokers, BrokerServers, and Adapters and therefore are normally defined as “running processes”, “daemons”, or “port-defined”. Typically, Development Level objects are created in the webMethods Enterprise Integrator development tool, while Infrastructure Level objects are created in the Enterprise Manager tool, Adapter Manager tool (or Adapter Configuration tool), and various command line utilities that come installed with their corresponding products. There is also the notion of “Common” objects in Enterprise Server. These are objects that are reusable and therefore have more Object Oriented look and feel. Common Objects are defined as Common Operations, Canonical Documents, Scripted Operations, and Configured Operations. Actually, the

Page 3: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 3

common object is where the majority of the product-specific difficulties arise described throughout the article. Below is a list of all the objects available in the Enterprise Server product and should be managed in the Source Control Management software:

Object File type Location Deployment Infrastructure-- BrokerServer and Brokers

Broker Server Configuration

awbrokermon.cfg

Unix: /opt /webmethods5/var/opt/webMethods/awbrokermon.cfg Win: C:\WINNT\activesw\awbrokermon.cfg

Broker Server configuration is created during installation of the Enterprise Server. Therefore, this file is more for version control and is not promoted through the environments. Additional Broker Servers are created manually using the webMethods command line utilities or Using Enterprise Manager.

Broker Configuration awbroker.cfg Unix: /opt /webmethods5/var/opt/webMethods/awbrokers50/default/awbroker.cfg Win: \EnterpriseServer\data\awbrokers50\default\awbroker.cfg

Brokers are manually created within an environment, using command line utilities or Enterprise Manager Tool

Infrastructure-- AdapterProcessMonitors and Adapters Adapter Server Configuration

monitor.cfg Unix: /opt/wment46/var/activesw/adapters40/monitor.cfg Win: \WINNT\activesw\adapters40\monitor.cfg

Adapter Process Monitors (Proc_Mons) are currently created manually in each environment, through webMethods command line utilities. Therefore, the monitor.cfg is mostly for version control purposes.

Adapter Configuration

1) Adapters_<ProcMon>.cfg 2)Adapter_Config_<Adapter_Type>.xls

Adapters_<ProcMon>.cfg: Unix: /opt/wment46/var/activesw/adapters40/adapters_<ProcMon>.cfg Win: C:\WINNT\activesw\adapters40\adapters_<ProcMon>.cfg

Adapters are created manually within their environments, through the Adapter Manager tool (or Adapter Config if using the 4.2 ADK). The adapter.cfg file is used mostly for version control. Each adapter should have a corresponding, manually created .xls spreadsheet used for source control and promotion of individual adapter properties through the environments—the products doesn’t allow for control of individual adapters. A spreadsheet is maintained for each Adapter, containing the properties of the Adapter (straight from the GUI tools)

“Development” Objects Integration Components

.adl Exported using Enterprise Integrator, using naming conventions

Each individual Integration Component is exported from Enterprise Integrator tool. Each individual Integration Component is imported from Enterprise Integrator tool or Broker_load utility

Page 4: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 4

Document Types .adl Exported using Enterprise Integrator, using naming conventions

Each individual Document Type is exported from Enterprise Integrator tool. Each individual Document Type is imported from Enterprise Integrator tool or Broker_load utility

Client Groups .adl Exported using Enterprise Manager tool, using naming conventions

Each individual Client Group is exported from Enterprise Integrator tool. Each individual Client Group is imported from Enterprise Integrator tool or Broker_load utility Note: Enterprise Integrator must be enabled for “Allow Client Group Editing” in the “Preferences” menu, to allow for Client Group Export/Import

“Common Development” Objects Scripted Operations .adl Exported using Enterprise Integrator,

using naming conventions Each individual Scripted Operation or Collection is exported from Enterprise Integrator tool. Each individual Scripted Operation or Collection is imported from Enterprise Integrator tool or Broker_load utility

Common Integration Components

.adl Exported using Enterprise Integrator, using naming conventions

Each individual Integration Component is exported from Enterprise Integrator tool. Each individual Integration Component is imported from Enterprise Integrator tool or Broker_load utility

Common Operations .adl Exported using Enterprise Integrator, using naming conventions

Common Operation or Common Operation Collections are exported from Enterprise Integrator tool at their Collection level. Common Operation or Common Operations Collections are imported from Enterprise Integrator tool or Broker_load utility, using the Collection-level .adl file

Common Documents (Canonicals and Reused document Types)

.adl Exported using Enterprise Integrator, using naming conventions

Each individual Document Type is exported from Enterprise Integrator tool. Each individual Document Type is imported from Enterprise Integrator tool or Broker_load utility

All-Inclusive Objects

All “Development” objects from Broker

.adl Option 1: Use Enterprise Integrator tool Option 2: Use /EnterpriseServer/bin/broker_save And /EnterpriseServer/bin/broker_load

Option 1: All objects from Broker are exported/imported from Enterprise Integrator tool by clicking on each Broker. Option 2: All objects from Broker are exported/imported, using command line utilities broker_save and broker_load. The command can be run remotely, but due to file size, it usually requires a user to login directly to the Solaris Operating System and FTP the file down to the SCM system. Typically, an all-inclusive object exported is useful when one needs to quickly replicate

Page 5: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 5

environments or one needs to promote from a Staging Environment to a Production Environment. Due to the physical disk size of an “all object export”, Option 2 will provide a smoother export/import. Traditionally, the GUI tools don’t perform well with large object export/import.

Broker Server binaries

.tar Unix: /opt/ /webmethods5/*.* Note: Must exclude opt/ /webmethods5/var/*.* because don’t want to include queue files and other variable files Win: /EnterpriseServer5/*.* Note: Must exclude EnterpriseServer5/data/*.* directory)

In order to perform software installation, SP, or Fix level rollback, it is necessary to control the current binary history of webMethods software.

Adapter Server binaries

.tar In order to perform software installation, SP, or Fix level rollback, it is necessary to control the current binary history of webMethods software.

Source Control Hierarchy All the objects listed above should be checked into the project’s 3rd party SCM tool. To better understand the objects, a SCM hierarchy needs to be implemented. There are multiple approaches to creating an SCM hierarchy, whether it adheres to the technical architecture or business architecture. Below is a sample SCM hierarchy that adheres to a webMethods technical architecture. Many variations of this hierarchy can be implemented:

Page 6: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 6

E nvironm ent-- D ev,T es t, P rod

awbrokerm on.c fg

awbroker.c fg

B roker S erver :P ort

B roker N am e

C om m on

S cripted O p/R esource O p.adl

IntC om p.ad l

C anonical.ad l

C om m on O p. adl

A dapters P rocm on

m onitor.c fg

A dapterN am e.xls

adapters .c fg

A llO bjec ts .adl

C om m on In t.C om p.adl

B roker S erverB inaries .tar

T ech S pec .doc

M apping.doc

Func tionalS pec .doc

Int Folder H ierarchy

Integration C om ps

P rivate D ocs .adl

O ther D ocs .adl

C lient G roups .adl

O perationsO perations

C om m on O ps .C om m on O ps .

D ocs /C anonicals

In t. C om ps

S crip ted/R esourceO p

Int. C om psInt. C om ps

Int Foler H ierarchyInt Foler H ierarchy

S cripted/R esource.adl

Page 7: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 7

Enterprise Server SCM Complexities: As mentioned earlier, many integration vendors have not yet provided SCM functionality directly in their products, which makes the integration methodology challenging. Listed below is an explanation of some of the complexities that exist in the webMethods Enterprise Server product suite, when dealing with an SCM implementation. Object Attaching during Exports: It is well understood that the webMethods Development Objects have complexities during the export and import process, especially when using the webMethods Enterprise Integrator IDE tool. The following is a detailed explanation of how objects attach to an .adl file when performing exports and imports. The main complexity with .adl exports, is that more objects get attached to the file export, then meets the eye. For example, an export of an Integration Component brings with it all Common Operations used within the Integration Component and all the Common Operations in the same Operation Collection of ANY Operation used within the Integration Component (make sense?). It basically means even Common Operations not used by the Integration Component can potentially, and most likely, get included in one’s .adl export. The same “attaching concept” holds true for Adapter Scripted Operations and Resource Operations (also called Configured Operations)—both object types get attached in the Integration Component .adl files. Therefore, the integration team needs to be aware of what objects actually exist in their .adl files--- chances are there is more than what was intended. Object Versioning: Specifically focusing on “Development Level” objects, there is no reliable feature for maintaining object versions directly in the toolset. There does exist a “Version” input field on the Enterprise Integrator (EI) Properties tab for each development object. However, this field is a user-defined field, which means that if each Integration Developer does not manually maintain the version numbers on this field, then the version methodology will fail due to non-compliance and developer forgetfulness. From previous projects, I’ve found it very difficult to get 100% developer compliance with maintaining the “Version” field, mostly due to the manual incrementation involved on the field. Developers are susceptible to forget to increment this field and the versioning therefore gets convoluted. Dependency Checking: There is no dependency checking amongst objects in the Enterprise Integrator framework. This means the tool does not alert developers about changing objects that affect other objects. This impacts the integration team on multiple fronts. First, when importing a changed Development Level object, there is no reliable mechanism for

Page 8: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 8

alerting about code overwrites. There does exist a “Sessions Log” in the lower pain; however, it is often difficult to enforce development teams to scour the logs every time they import an object. Therefore, there is no protection from overwriting an object, because a dependency alert does not occur during object import. The second difficulty arises when multiple developers work on the same Broker—this design architecture is easily susceptible to one developer overwriting another’s code when saving their Broker session. Having multiple developer sessions to the same Broker, makes the Broker highly susceptible to a race condition—the last developer to save his work, will provide the current object set in the toolset. Their exists a simple rule to overcome this complexity when developing on a Broker project—1 Developer per Broker will prevent the team from stepping on each other’s feet. 1 Triggering document per adapter An adapter can have multiple integration Components; however, each Integration Component triggered by a document, must be triggered by a unique document. There cannot exist 2 enabled Integration Components, within the same adapter, that are triggered by the same Document Type. This complexity provides a constraint when trying to create multiple versions of the same Integration Component, within the same Broker—the case where 2 versions of the same Component exist and are triggered off the same documents type version, means one of the components must be disabled. Obtaining individual Adapters Because the webMethods Adapter Manager places all adapter properties in one configuration file for a particular machine, it is difficult to source control individual adapter properties. Therefore, it is highly recommended for the integration team to maintain an individual Excel spreadsheet for each configured adapter. This ‘manual process’ of maintaining Excel sheets allows the team to check-in and checkout individual adapters from the SCM, using the Excel spreadsheets as the controlling objects, as opposed to the grouped adapters in the configuration file(s).

Methological Workarounds: There are multiple approaches to addressing the complexities mentioned in the previous section. Each approach can be implemented separately according to one’s environment No Collections The concept of Common Operation, Adapter Scripted Operation, and Configured Operation Collections (also known as “Shared Objects”), is what has initiated the object-attaching complexities discussed in the previous section. Collections obviously help with the manageability of objects in Enterprise Integrator (EI) graphical representation, but present the bulk of complexities related to object-attaching concerns. This is why the integration team needs to determine whether even to use Collections in the integration implementation; the team needs to measure the cost of using Collections vs. benefits of

Page 9: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 9

using Collections for their particular environment. One option to overcome the Collection difficulties discussed, is to migrate all the Common Operations, Adapter Scripted Operations, and Configured Operations outside of Collections. Therefore, the objects now reside directly in their corresponding Adapter hierarchies; the Collections can be deleted from EI and removed from the implementation. This approach works best if the implementation has few development objects to manage and if the team has not deployed the objects to a Production environment; the collections will still exist in Production and therefore require some Production downtime to remove the Collections in Production. This is because, even if you migrate all your Operations outside of Collections in a non-Production environment, but promote to an environment that still maintains the Collections (ie..Production), the Operations will automatically jump back into their respective Collection hierarchy. There is a potential hack into correcting this Operation merging behavior by editing Operation’s document infosets using the BrokerAdmin API, but it would be a risky hack at best. Therefore, the approach of not using Collections works best when starting a new implementation and Collections don’t already exist within the environments.

Source Control Collections: A second architectural option is to Source Control the Operations at the Collection level, as opposed to individual Operations. This would require the integration team to export each Operation Collection from Enterprise Integrator and check-out/check-in each Collection from the SCM tool. This approach provides the benefit of not having to migrate all the Operations out of the Collections, because the code is being maintained at a higher hierarchical level. However, it also limits the level of granularity that individual Operation management did allow, because Operations are being controlled in groups, as opposed to individually. The Collections can be organized by functionality or another mechanism that aligns with the integration project grouping standards. Depending on the number of Operations that exist in the Collection, a Developer could potentially lock-up (check-out) a large number of Operations, when he only needs to change one Operation within the Collection; the granular level of control is now lost This approach works best in two scenarios (1) when Collections are already defined in the integration environments, and (2) if the team plans the Operation segregation carefully (i.e. how to architect Operations in different functional Collections). Collections Align w/Integration Components: The third approach involves aligning Operation Collections directly with the Integration Components that use them. Therefore, an Integration Component will only use Operations from its corresponding Collection. Each Integration Component will have 1 corresponding functional Collection. This approach overcomes the limitations from the object-attaching quirks, because Integration Components will only be importing Operations that it actually uses (as opposed to Operations it does not use) because all the Operations within a Collection will be imported. The downfall with this approach is that there is little object reuse, due to the fact that Operations cannot span multiple Integration Components. For example, each Integration Component will maintain separate Common Operations that have the exact same functionality, but reside in different Collections.

Page 10: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 10

This could result in the same Operation being physically duplicated throughout the environment, just to align with the Collection rules—its possible to have getSystemDate1, getSystemDate2, getSystemDate3, etc, each residing in a different functional Collection. Again, it is cost vs. benefit analysis—what is the cost of creating multiple copies of the same object, if it avoids the risks involved in object attaching (benefit). This approach works well when there are few Common Operations within the integration system and therfore it is not expensive to create multiple copies of the same objects. Naming Conventions and Versioning This section describes how to apply versioning to the development objects within the Enterprise Server toolset; it is not intended to suggest how to functionally name the objects within your integration architecture—ideally the integration architect has decided the naming standards that will be applied to each Integration Component, Document, Operation, and Client Group. The following paragraphs only describe how to apply versioning to the established naming conventions already in place. Any versioning naming conventions applied to the webMethods development objects need not be complex; a simple numbering scheme will suffice for most Enterprise architectures. The real purpose of the object versioning is to allow the developers to understand the latest release of a development object, allow the developers to maintain multiple versions of an object simultaneously within the webMethods tools, and provide developers another layer of protection from promoting an outdated object through the integration environments. There are slightly different approaches to version naming conventions, depending on whether the project already has an implemented integration codebase or if the project is starting anew. When starting a new project, there is simple rule to apply: A version number should supersede each Development object name. For example, an Integration Component normally named “PurchaseOrder_Target” should be named “PurchasedOrder_Target_v1”. This convention provides a simple version for the object and is explicitly displayed in the webMethods tools. When an object is checked-out of the Source Control Management software and imported into the toolset, the object will exist within an environment with its current version easily obtainable. If the developer plans to modify the object he just checked out of SCM, he should immediately make a second copy of the object, using the copy/paste feature of Enterprise Integrator. The second object should have the next increment of the object’s version in its name. Deleting the original object is optional, but may be best, so that the developer doesn’t accidentally make a change and check-in the wrong object version. For example, the renamed object with incremented version number should be “PurchaseOrder_Target_v2”, existing simultaneously with “PurchaseOrder_Targetv1” (if not deleted from EI). Because of the complexity of 1 Integration Component per triggering Document Type (See Product Complexities section), more often than not, the Integration Component’s corresponding Document Type must also be checked-out of

Page 11: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 11

SCM and incremented with the next version number for the Document Type as well (See Dependency Checking section). Another approach to overcoming this particular complexity is to have one of the Integration Components “disabled” to allow a second component with the same triggering Document Type to exist within the Broker. When implementing the Naming/Versioning standard to a project that has an established codebase, the team can follow the same rules outlined above. The only exception is that the objects in the existing code base are intuitively versioned as “v 1”, without going into EI and renaming all the implemented objects. All subsequent object versions increment to “v 2” are named “v 2” within the tools. The object names can then be incremented, as stated in the preceding paragraph. This approach prevents the team from renaming the objects in the existing code base, which may already exist in Production. Because multiple versions of objects can exist within the developer’s toolset, it is the developer’s responsibility to periodically deprecate objects from his tool. The cleanest approach to this is to delete the deprecated object from the developer’s webMethods toolset session. This approach is safe because the deprecated object is not lost; it still exists as a labeled object in the SCM software, offline from webMethods tools. Object Versioning and Naming Conventions have additional value, when performing “In-flight Object Promotion”. In-Flight promotion is defined as promoting code to a live integration environment (Production), that has documents processing on an established codebase, but needs to switch to an upgraded codebase, without affecting the documents that are “in flight”. With the versioning naming conventions described above, multiple object versions can exist in Production simultaneously. The Integration Administrator now has the flexibility to allow documents on the older codebase to finish processing before enabling and switching the Production code to the newer codebase version he promoted. Documents can process on two simultaneously codebases, due to the fact that versioning was part of the object naming convention. A lot of responsibility relies on the development team members to adhere to the versioning rules; however, if followed correctly, these approaches provides a flexible guideline that overcomes some of the complexities integration customers are dealt with. Impact Analysis As described in the Complexities section, the current Enterprise Server development tools do not provide dependency checking amongst shared development objects. For example, a developer could checkout a shared Document Type from SCM; make modifications to the Document Type definition, and check-in the Document Type to the SCM. Unfortunately, because the Document Type is shared amongst developers and their integration code, any modifications to the Document Type would impact the other objects using the Document Type. To prevent object modifications from ‘breaking’ its dependent objects, the developer checking-out the shared object needs to perform an “Impact Analysis” on the object being modified. The Impact Analysis helps avoid the risk of overwriting objects, with outdated versions of the same object. To best organize the Impact Analysis, the integration team should maintain a spreadsheet for each shared

Page 12: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

object, outlying the objects relying on the shared object. When a developer prepares to modify an object that impacts another reliant object; the developer needs to determine the appropriate action to perform on the impacted object, so not to break the integration code. Traditionally, a decision tree can help the developer decide what actions to take for each scenario he encounters. Perhaps the developer needs to checkout the entire set of dependent objects from SCM as well? The actions taken by the developer will be based on each project’s decision tree. Some actions include: checkout and modify all impacted objects with the modified object, checkout and not modify impacted objects (hence, locking the objects from others to change), do nothing to impacted objects, or any variations of these actions. No matter what action is performed, all objects modified and impacted need to be retested in the appropriate integration environment, according to the project’s testing guidelines. Standard Procedures There are certain standard procedures the project team needs to adhere to, in order to effectively operate in a shared, multi-developer environment. In fact these procedures relate to the complexities of creating “Shared Objects” amongst a team of developers. Order of Object Promotion Because integration development is occurring in a shared environment and object attaching is a concern, specific import procedures need to be adhered to prevent object overwriting to a previous version (“Object Out-dating”). Described below is a sample flow chart, showing the path of object importing, within distinct logical environments. The following import procedures assumes, at minimum, the following logical environments exist:

Prod StagingTest DEV The following are sequential procedures for object promotion: Dev to Test

Listed below is a sample sequence to follow when promoting objects from logical Dev to logical Test environments

1. Create Broker Servers using server_config command line utility. Note, Broker Servers may have already been created from a previous object promotion or if only using a single Broker Server, then they were created during product install

2. Create each Broker using the Enterprise Manager Tool or Broker_Create

command line utility. Note, Brokers may have already been created from a previous object promotion.

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 12

Page 13: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 13

3. Check out each Adapter.xls spreadsheet from Source Control System (SCM) to obtain the connection properties needed to create or edit the adapters in the target environment. If the adapter properties are quite similar from the 2 environments, Adapter Manager allows one to copy/paste the Adapter Objects.

4. Create or edit the necessary Adapter Proc Mons and Adapters, using the

Adapter.xls spreadsheet as guidance. Adapter Proc Mon will be created using the adapter_procmon command line utility, while the Adapters are created using Adapter Manager 4.6.x.

5. Check out the necessary Integration Component .adl files from Source Control

System (SCM)

6. Import each Integration Component individually into their respective Brokers, using the Enterprise Integrator tool or Broker_load command line utility. Rename the Integration Component, following Naming Standards and Object Versioning Methodology

7. Check out the necessary Document Types .adl files from VSS

8. Import each Document Type individually into their respective Brokers, using the

Enterprise Integrator tool or Broker_load command line utility. . Rename the Document Types, following Naming Standards and Object Versioning Methodology

9. Check out the necessary Common Operation Collection .adl files from VSS

10. Import each Common Operation Collection individually into their respective

Brokers, using the Enterprise Integrator tool or broker_load utility. Rename the Common Operation Collections, following Naming Standards and Object Versioning Methodology

11. Check out the necessary Adapter Scripted Operation Collection and

Configured/Resource Operation Collection Component .adl files from VSS

12. Import each Common Integration Component into their respective Brokers, using the Enterprise Integrator tool or Broker_load command line utility. . Rename the Collections, following Naming Standards and Object Versioning Methodology

13. Check out the necessary Client Group .adl files from VSS

14. Import each Client Group into their respective Brokers, using the Enterprise

Integrator tool or Broker_load command line utility. . Rename Extras External Clients, following Naming Standards and Object Versioning Methodology and ensure the External Client points to its appropriate Client Group.

Page 14: INTEGRATION & SOURCE CONTROL · PDF fileControl software, specifically how to seamlessly “integrate” webMethods-specific ... from Enterprise Integrator tool or Broker_load utility

Copyright Visual Integrator Consulting, LLC 2003 www.visualintegrator.com 14

15. Run the Broker_Build All command line utility for each Broker in Production that had code promoted.

Test to Staging Similar procedures as DEV to Test code promotion, since objects are being promoted in piecemeal fashion. Staging to Production Traditionally, a logical Staging environment is a familiar webMethods Best Practice. A Staging environment allows for the implementation team to promote all Development-level Objects within a particular Broker, in one .adl export file. Having one .adl file for this stage of the promotion, creates a simple final step in the promotion process, rather than promoting objects in pieces to the Production environment. Therefore the code promoter can checkout the Broker.adl file for each Broker in the Staging environment. The .adl file can be imported through Enterprise Integrator (although, not recommended to allow Enterprise Integrator to access Production) or the command line utilities provided by webMethods Enterprise Server. The command line utilities are highly recommended, due to increase performance, control over optional parameters such as memory heap size, and risk of Enterprise Integrator ‘touching’ unattended objects during its session to the Broker. Scripts Since many of the steps required in Enterprise Server maintenance and promotion can be achieved through the webMethods Enterprise Server command line utilities, these steps can be automated through the use of reusable command-line scripts. Using scripts is highly encouraged, since it helps prevent manual, human error during the source control procedures—instead of manually promoting objects, one can run the pre-defined scripts. Typically, the scripts will use the operating system’s scripting language Conclusion There are many Source Control Management procedures not addressed in this article, but at minimum, the article provides a vendor specific approach to controlling objects within webMethods Enterprise Server. The article can be used as a guideline for expanding specific SCM methodologies throughout the integration lifecycle. Contact: Visual Integrator Consulting can be reached via email at [email protected] or via the World Wide Web at http://www.visualintegrator.com