I want to make an archive of my Java Service. The Java Service has shared code in the webMethods Developer, look at the screenshot below (click it to get larger view):
In the webMethods Admin Panel → Package → Management, click the Archive icon on a package row. Next, there is a Selection Files List Box (look at the screenshot below, the list box is given with red box):
I want to know what are files I have to select in order to include the Shared code in the Archive?
I would suggest archiving the entire package, not just parts of it.
Common code is stored in the .java files in the code/source directory.
I found out that the shared code are put in a .java file, meddled together with the non-shared code.
For example, in webMethods developer, if we create a or several java services with a folder path:
/com/company/util
in package folder, system will create a file path:
/code/source/com/company/util.java
The compiled class file path:
/code/classes/com/company/util.class
The java file pattern is:
/code/source/ + class_path + folder_name.java
The class file pattern is:
/code/classes/ + class_path + folder_name.class
The util.java will contains all of java services plus the shared code that we created in /com/company/util folder.
It happens that shared code is only shared for all of java services in same folder. For example, if you have two folder contained java services:
A) /com/company/util
B) /com/company/tool
The shared code in A will only be available for A, and the shared code in B will only be availabe for B.
To archive the shared code, I think the files that must be selected in package management list box is the .java and the .class file, so for /com/company/util example that would be:
/code/source/com/company/util.java
/code/classes/com/company/util.class
Is that right?
Yes. This is described in the documentation.
I would suggest archiving the entire package, not just parts of it.
So is that mean each time I changed the shared code, I have to archive entire package?
I’m planning to export what I have done in development webMethods IS server to production webMethods IS server by using archive. Usually, we are just archiving what we have changed by selecting manually the files. If we archive entire package, there is possibility of unused/testing service being included into the archive which we don’t want to.
The package export/archiving facility does allow for creating “patches” – select only the changed elements.
I usually avoid that approach because it can be error prone–miss one of the key elements or include one that you didn’t intend to.
I normally recommend dealing with a package as an atomic unit. Similar to a Java class. It all goes or nothing goes. It’s easier to deal with deployment-wise. If you’re not doing so, I strongly recommend updating the package version field for each release so that you know what is deployed where.
Test services should not be in the package that is to be deployed. Instead, create a separate test package. Say your package name is “ABC.” Have test package name “ABC_Test.” In that test package you can do whatever you need. Never deploy it to production.
How often are you changing shared code? How much Java code do you have? If you find yourself doing a “lot” of Java then you may not be leveraging FLOW as fully as it can be.
Hi,
There is one thing lacking on my previous post regarding of exporting shared java code. We also need to export the node.idf from the java service folder. Here is the update:
For example, we had created one or several java services in a folder:
/com/company/util
To archive the shared code in that folder, the files that must be selected in archive list box are:
code/source/com/company/util.java
code/classes/com/company/util.class
ns/com/company/util/node.idf
Of course, don’t forget to choose Selected files in “Files to Include” options, and the “Archive Type” value would be Patch.
I would suggest archiving the entire package, not just parts of it.
I normally recommend dealing with a package as an atomic unit. I recommend avoiding the use of patches.
There is also a problem in archiving entire package. Sometimes the adapter settings between servers are different. So overwriting the destination adapter would cause a problem. Of course we can modify later the adapter after patching, but in case there are many adapters, this would be inconvenience. In that situation, I will archive the entire package but exclude the adapter. Here is how I do it:
For example, I had created a JDBC adapter in this path:
/com/company/conn/myAdapter
Note: I will suggest to make a specific folder for storing adapter only and not to put other object besides adapter inside. In above example, I will put all of adapters in /com/company/conn/ folder.
In Archive file listbox, set the Files to Include option to “All except selected files” and select these files:
ns/com/company/conn/
ns/com/company/conn/node.idf
ns/com/company/conn/myAdapter
ns/com/company/conn/myAdapter/node.ndf
The trick is just find the file path that started with adapter folder path (/com/company/conn/) and select all of them. This is why I suggested to put adapters in one specific folder.
There you can export the entire package without worry of overwriting the destination adapters.
Here’s an approach that I’ve seen taken in almost every engagement I’ve worked on:
Adapter connections are placed in their own package(s). They are never placed in packages with any other code/service. This is much like you suggest with putting them in their own folder–but instead, put them in their own package.
Such packages might be archived but are never deployed to other environments. Instead, the adapter connections are defined manually in each environment (dev, test, prod). It sounds like a lot of work but it really isn’t.
This avoids the possibility of an integration pushing test data to prod and vice versa which is usually a Very Bad Thing. 
In our differents environments we use the “Variable Substitution” ability of the Deployer which overrides the parameters of the differents adapters which are in your builds.
It has to be defined in each environments just one time and modified when you add new adapters, and that’s all.
Hi reamon,
I think your appraoch is better than mine as I just met an issue that if you use my approach and you happen have renamed some objects’ name and when you use patch mode, the renamed objects in source package will not synchronize with the objects in destination package, so you will end up with redundant objects that needed to be deleted manually.
So for easy picture, it’s like this:
I renamed “Service1” to “MyService1” in source, then I deployed to dest. server. Now I got:
My question is if I use your approach, which use separate package to store the adapters, would it cause a performance issue when making a connection/query to database?
Hi arnaudW,
How do we know if our webMethods IS has Deployer installed? I’m not sure if my webMethods got Deployer or not.
No.
Hello, Can somebody help me with the documentation link for java shared code service?
Thanks!!
Hi,
When Deployer is installed on your IS you will find an entry the navigation bar of IS Admin UI named “Solutions”.
Under this you will find a link to the Deployer.
Remember: when deploying adapters with variable substitution, they need to be disabled during the packaging (when taking the build).
Otherwise deployment will take quite long especially when source servers for the adapter targets are not reachable from the target servers, i.e. due to firewall restrictions.
Regards,
Holger