Version Control with Various webMethods Products

, ,
1

It looks like only the webMethods IS Service Components can be moved to the Version Control using the appropriate Plugin from Designer

Here is my understanding of how to check in various code/Config for each product based on a CI-CD setup I did with version 9.9 .Please let me know if im wrong somewhere or theres a better way.

IS Services-Use the appropriate plugin for the Version Control Tool for Designer-I used the Polarion plugin for Subversion

Business Process Models-No idea how to check in from Designer-Maybe we need to export the model and check in to Version Control.

TN Components-Export as file from MWS and check in

Active Transfer-Export the data using bult in Service and check in.However you will not be able to use ABE to deploy as this is not supported(yet)

MWS-Export Components as File and check in.

UM-Export the config file and check in to VCS

Apama-No idea-Any pointers would be helpful

I would have preferred a way to check in code/config from the place where it is being developed,For Eg If im configuring TN components in MWS ,I would prefer to be able to check in the components from MWS itself. This would add to the whole “Automated” user experience as exporting and checking in files from file systems are error prone

On a related topic. If I am to set up a Continous Integration-Continous Delivery setup…It looks like currently I can only do that for IS Services using the local Workstation Feature.

What if I need to set up similar setup for the rest of the Products that are used in the solution(BPM,TN components,CAF pages,Apama analyics etc)?Do I need to install the entire tool set (with database and all) locally?That would be a bit of an overkill .Not sure if our current stock supplied laptops can handle all of them.

Also as per the Documentation the ACLs are not checked in to the Version control as its set on the IS.
So this means that an administrator would need to set it manually in the target server/s.
Now I would think this is a problem as the whole promise of the Devops-CI-CD thing is automation.So why does there need to be a final manual step for something as trivial as an Access Contol List.
Hopefully this is on SAGs to-do list

2

Hi Vargehese,

you can put all process projects, rules projects and UI projects (all things being designed locally and then “build&uploaded” to the corresponding runtime instance) under SVN using either Subclipse or Subversive Eclipse plugin applied to Designer.

For Services/TN Assets this is possible when you are using Designer 9.12 and newer with the Local Service Development feature.
TN Assets are not stored in MWS, MWS only holds the UI to use corresponding services on IS/TN Server to configure the TN server/services.

Designer 9.12 is backwards compatible to nearly all wM Versions (at least to 9.5 SP1 and newer).

For ACLs I am not a friend of deploying them, but I usually mark them as existing as this is a one-time task upon first deployment and does not need to be repeated on evey deployment.
This means the ACLs need to be created and configured BEFORE deployment.

Regards,
Holger

3

Thanks for the reply Holger…

I rechecked again saw that I could “Share Project” from the navigator view from the Process Development Perspective.(Unlike the Service Development where i can commit right from the service)

I am going to try and see how the automated build will work on the other Side of the version control in my Continous Integration- Continous Delivery setup.

Process Model Source code maintenence was a major pain point in one of my previous projects.

Re the ACLS…what I meant was that as per the documentation(Service Development Help), the ACLs that are set in the services are not checked in to the Version Control and need to be manually set in the environment that the ABE is pushing it into

“Permissions
Access control lists (ACLs) determine the level of access to packages, folders, and other
elements (such as services, IS document types, and specifications) at the group level.
ACL se?ings are stored on the local development Integration Server, not with the
elements themselves. This means that ACL information does not get checked in to the
VCS repository when you check in an element. When another user checks the element
out of the VCS repository, that user’s local development server uses the default ACL
to determine access to that element. You can preserve ACL se?ings for an element by
deploying the element from the local development server and then se?ing the element’s
ACL se?ings manually on the production server. For more information about ACLs, see
“Assigning and Managing Permissions for Elements” on page 89.”

1 Like
4

Re TN Assets…I understand that MWS is just thee UI…My point however was the ease of checkin for Developers,its always best to check in directly from the place that they are configuring/Coding.Eg if I make changes in a processing rule,i would like to be able to check in to version control from the place Im making the change ie from MWS

5

Hi Varghese,

for the generated parts of the Process Models (Packages/Services etc.) see the approach for Service Development.
When implemented correctly these should change very often (only when the design of the model changes).
Separate package for the process generated parts invoking an implementation service in a different package (the steps should be marked as IS service Steps having the service to be invoked assigned in the step properties. Any logical changes to the steps can then be handled without affecting the process definition or generated parts.

When using Local Service Development feature the ACL definition needs to be shared between all the Designer installation using this feature. For this there are five configuration files to be checked into Subversion from local IS development Server:

  • acls.conf (contains all the acls defined with their groups/roles which are allowed or denied as )
  • acllist.cnf (the acls assigned to the ListACL property of the services)
  • aclmap_sm.conf (the acls assigned to the ExecuteACL property of the services)
  • aclread.conf (the acls assigned to the ReadACL property of the services)
  • aclwrite.conf (the acls assigned to the WriteACL property of the services)

Additionally it might be neccessary to share the users.conf this way, which holds the users and groups which are local to the Local Service Development IS. Most likely this file is only needed for the local service development users but not for higher environments.

These forementioned files need to be synchronized to the local workspace before synchronizing the elements which are using them.
It might be neccessary to restart the local development server to activiate the changed configurations.

It is advisable to have main development IntegrationServer instance, where all locally developed parts are put together and transported from there to higher environments (test, qa, production).

Regards,
Holger

1 Like
6

TN Assets are visible in the Service Development perspective of Designer and are usually stored in a database schema.

Therefore neither IS itself nor the MWS have a direct possibility to maintain these under Version Control.

If you want these things to be changed please open featue requests in brainstorm for them and we will see what others think about it.

Regards,
Holger

7

Just to make sure we are talking anout the same thing…TN components like Processing Rules,TPAs,Document Types etcs are created/modified via MWS(Before that we had TN Console).
Are you saying that these can done from the Service Development view and checked in to version Control in 9.12?

8

Hi Varghese,

TN Console has been deprecated in 8.2 and has been replaced by TN MWS UI.

You will have to add/change etc. the TN Assets in MWS UI, but they are visible in Service Development view as a separate group.

Therefore I thought they might be checked in from there.
If this is not possible you will need to export them via MWS UI and check in these exports.

Regards,
Holger

9

Holger

Got it …many thanks

I see the Trading Network Document Types package in the Package Navigator in Service development.(See attachment).This looks new .will need to check out its usage …but I checked and I cant create aTN doc type from here ,nor can I modify any of the existing stuff there

I will raise a feature request.

10

Hi Varghese,

this should be the case for all Designer which have at least a remote Service Development plugin available and TN is configured in the IS Admin.

BTW:
You have omitted the attachment in your last post.

I currently cannot check this by myself as I am working with an older version which do not have Local Service Development installed.

You are supposed to maintain the assets via MWS UI which in turn trigger the appropriate actions in IS/TN server instance.

Regards,
Holger

11

Sorry here it is

TNDOctype.PNG
TNDOctype.PNG485Ă—663 34.1 KB