Get a webmethods package from github into your service designer

[Martin_Wroblinski]

Introduction

Versioning your assets in webMethods Designer or webMethods Service Designer is nearly the same as with every eclipse project. But as we are always working with a server, 2 additional steps are needed. In this article I'll show you how to get a webMethods package from git or github into your Designer workspace. If you want to add a package you created in your local environment into git, please have a look at this article.

This only works for local service development. If your development server is not running on the same machine as Designer, this won't work this way. Service Designer is already preconfigured with a local server, so this will work for Service Designer.

Preparation

You need to start Designer as Administrator for using VCS integration. This is because Designer needs to create symbolic links so Designer and the Server can access the same files.

In Designer go to Window - Preferences - General - Workspace. Enable Refresh using native hooks or polling.

Package structure

A package is the delivery unit of assets for webMethods Integration Server and Microservice runtime. On your working or runtime environment it is just a folder on your disc and all assets are within this folder. Therefore it can be easily versioned just from the files system. The easiest way usually is to do this directly from within Designer. The folder defining the package containes different subdirectory like code, ns, ressources etc..

Get a package from git/github

Go to the Git perspective (or open the Gi Reporitories view)

Select Clone a Git repository and add the clone to this view. Enter the connect information for your repository.

Select the branch(es) you want to work with.

Select a local working directory. With Git it is not recommended to place this into the Designer/Eclipse workspace.

You need to import the package as a project.

Right click on the folder which is your package. Select Import Projects....

Click Finish.

Go the the Service Development perspective. You wont see the package in the Package Navigator yet.

Go to the Package Explorer view. Rightclick the Project you just imported and select Move Project to IS package.

Go to Package Navigator. Rightclick the server Default and select Refresh.

The package is now available in the Service Development perspective for working with it. The small circle at the package name indicates that the package is under version control.

[Aviv.Simionovici_emp]

using the latest Designer 11 there are 2 corrections:

1. The local working directory can be inside the Designer/Eclipse workspace. This is also recommended if you use git as WM package repository to develop once - deploy anywhere.
2. “Move Project to IS Package” is “Reload IS Package” in Designer 11
   
   

[jahntech.cj (Christoph Jahn)]

Here are my thoughts on organizing source code on the file system of my development machine and working with it.

• I always have a directory with the package name within my GitHub repo.
  • The alternative would be to have the package files (e.g. manifest.v3) at the top level of the repo. The latter has the advantage of being able to clone directly into a directory with the package with something like git clone https://host/my_pkg My_PKG.
  • However, with the package as a sub-directory I can also version related things. The obvious example would be a test package. But also documentation, build logic, etc. are candidates here.
  • As long as Designer clutters the workspace with automatically generated packages for Java development, I don’t want to use the workspace for anything else. It is simply confusing and makes, at least for me, work harder.
• I never use the Eclipse Git client. For me the Eclipse approach to abstract away some specifics of the VCS makes things confusing. Instead I use a combination of TortoiseGit, VS Code, and the command line client.
• The new name (“Reload IS Package”) is misleading in my opinion. We can certainly discuss whether the old one (“Move Project to IS Package”) was ideal or not. But the new one, apart from the fact that a change will always cause some level of confusion, is not an improvement from where I stand.
• Without having done any “formal” testing, it seems to me that at least with v10.15 I don’t have to start Designer as administrator to make the symlink creation work. The user on my Windows 10 environment can be elevated to admin privileges, but I do not get the respective question. Instead things just work, which is a nice improvement compared to v9.12.

Last but certainly not least: Thanks a lot, @Martin_Wroblinski , for this nice article!

[Martin_Wroblinski]

Hi Aviv,
that’s not correct, Reload IS package and move Project to IS package are two different functionalities and (I just checked with Service Designer 11.0) the naming is still the same:

• Reload IS package does a reaload on a package which is already in the IS/MSR package Dir, just like you can do from the IS/MSR admin. It is visible in the context menu of PackageNavigator.
• Move Project to IS package links a package directory which is an eclispe project but not yet a package inside IS/MSR into the package dir and makes it avavilable in IS/MSR. It is visible in the context menu of PackageExplorer if the package has the LocalServiceDevelopmentNature and is not yet a package in IS/MSR.