An easy way to hide Java code on webMethods

Why

Sometimes when you release a package on webMethods, you probably don't want to expose the detail  of your Java service, so somebody else could not modify your code, or you just don't want them to know how genius you are. Well, there is an easy way to hide your Java code just like what they did for Wm* packages.

How

If you take a look into the folder which holds your Java service, you would see a file named "java.frag". It's actually an XML file which contains unreadable weird string. That weird string would be base64 decoded back to Java code exactly the same as what you would see in Designer. You could try to decode it on some free web site, for example https://www.base64decode.org.

What

To hide the Java code, you will need to remove all java.frag files when releasing the package. When you try to archive the package on IS Administrator UI, select "All except specified by filter:" and type "*.frag" as the filter value. Now your genius idea would be a secret.

But

Unfortunately, the secret won't be kept too long. Once somebody export your package to local, then they could decompile class file to find out what you're hiding. There is another way to hide Java code even after exporting the package, but that's another story.

Connect to SFTP with both password and key on webMethods

Problem

I couldn't recall since when webMethods starts to support SFTP client. Maybe version 9? It's a great feature, so we could connect to SFTP server easily, but it's not perfect. To connect with a SFTP server, we need to configure a User Alias first, but we could only select either Password or Public Key as the Authentication Type. What if your server is asking for both? You will get an Auth fail exception when you try to login.

Reason

When service pub.client.sftp:login is invoked, it will call method public Session SFTPClientManager.login(String userAlias) to establish the connection with SFTP server based on the User Alias information. The connection would be established differently based on your choice on Authentication Type field, but none of them would handle both Password and Public Key correctly.

Solution

What you need is a customized login service which could retrieve Password and Public Key from User Alias and handle them correctly. With that you could even reuse the generated Session with other services under pub.client.sftp folder as a native one.
To use this customized login service, you will need to:

1. Create a SFTP User Alias on IS Administrator UI as usual.
2. Make sure this User Alias is configured twice for different Authentication Type. For example, firstly you configure it to use Password, and after saving, modify it to use Public key.
3. Invoke service HxEnhancedSftpClient:login to connect to SFTP server by the given User Alias you created in step 1. This service has the exactly same service signature with pub.client.sftp:login.

You could download this package form GitHub, https://github.com/dingago/HxEnhancedSftpClient. The code is verified on webMethods 9.9 and CrushFTP 9.

Comments

• If you're having issue Invalid private key, you probably need to regenerate the private key in PuTTY format, which is generate by PuTTYgen.
• If you're having issue The cipher 'xxx' is required but it is not available, you probably need to replace current JCE jars.