I have a query regarding Package naming and root folder name, my questions are
One of my client is using webMethods, but they are following their own package structure, means
Package name:Orgname_BusinessFuctionality_FuctionalName (ex: Pcm_HR_LeaveDetails)
Root folder name : Pcm
Sub folder : hr,
Service name: leaveDetails
Here My concerns are,
why we need to create package and root folder name as same ??
If we follow above structure, what will be the impact ??
how do we tell strongly to client , this is not best practices ??, is there any strong evidences , please provide it.
I know it is best practice recommended by SAG, should be same name means Package name and Root folder name, then only it will give fully qualified path, we can use this fully qualified path for identify elements at package level.
Actually package name is not part of fully qualified path, the fully qualified path means it will consider like root folder.sub folder.sub folder: service name. it will difference from physical package name to logical package name.
as the package name is not part of the fully qualified path (the namespace path of the node inside IS) you will not be able to know which package the node is located in.
PackageNames should not start witth Wm* or Wx*, as these are reserved for packages provided by SAG and are not be visible in Deployer. Services located in here can associated with the proper package by the second part of their folder structure (i.e. pub.prt for ProcessEngine related services).
Therefore it turned out to be a best practice to name the top folder of a package the same as the package itself to easily identify the package where the node is located.
For your example, the service will have the following name: pcm.hr:leaveDetails but the package name is PCM_HR_LeaveDetails.
Is this right?
I assume, that there are more than one HR services in this context, right?
Thena better structure might be to group all these services in a package named PCM_HR and name the services like that:
PCM_HR.services:leaveDetails being PCM_HR the top folder in this case. You can that docTypes under docs folder or adapter releated things under adapters folder which should belong to the PCM_HR context.
I don’t think it’s a best practice. It’s just one of the possible ways to organize assets, but not the only one. BTW, assets in e.g. WmPublic do not follow this practice.
There are some advantages and drawbacks. The fact that it’s easy to tell what package the service resides in, does not matter much IMO. It’s easy to find out anyway even if the root folder does not have the same name as the package.
If you organize your namespace regardless of the packages, you’ll be able to physically move assets between packages without the need to change the clients. Also, managing ACL will be more flexible and easier if you have some root folder sequence that corresponds to your organization (e.g. “com.acme”).
We do not follow this practice and so far don’t experience any inconveniences.
Thanks for your response. really it is helpful information from yours…
I went through other forum threads as well, some one follow package name and root folder name and others follow package name and root folder name is different. they said root folder name is not mandatory with same name alien with package name. it is also not a wrong approach to follow package name and root folder name different, please correct me ?.
actually I am looking main advantages and disadvantages if we did not follow package name and root folder name not same.
when moving assets around in Designer from one package to another, usually Designer will take care of the dependencies if neccessary.
As the packages Wm* and Wx* are internal IntegrationServer packages it is up to SAG webMethods R&D how these are structured.
You should check that you use a different naming scheme than the internal scheme to distinguish between nodes provided by SAG and nodes your are providing, whether you use “root folder = package name” or not.