Hi All,
We are currently on webMethods 9.10 version. Can we deploy UM artifacts/assets from deployer tool.
I’m unable to find the UM option from the dropdown where we select the Type of component.
Thanks & Regards,
Monica
Hi Monica,
please have a look at the Deployer Users Guide for your version available thru Empower or from here:
http://techcommunity.softwareag.com/ecosystem/communities/public/_communities/documentation
Chapter 4 “Starting Deplyor and Connecting to Servers” has a sub-chapter “Connect to Universal Messaging Servers”.
Also have a look at Appendix D “Universal Messaiging Assets” in the same Guide.
Do you have a package WmNUMDeployer on your IS where Deployer is installed?
If not, you might have missed a component during installation.
Regards,
Holger
Thanks Holger.
I have configured to connect to UM Servers.
I also have package WmNUMDeployer installed on IS where Deployer is installed.
Is it true that UM assets can be deployment only from ‘Repository’ [meaning source to be repository and target to be another UM]
or can it be done as ‘Runtime deployment’ [meaning source to be one of the UM and target to be another UM]
Please confirm.
Thanks,
Monica
Hi Monica,
I am not using UM at the Moment as we are still on 9.5 using Broker.
I came across this information in the Deployer Users Guide.
I am not sure if this has a technical reason or it simply has been overseen.
You can try to open an idea in Brainstorm requesting Runtime Deployment possibility for UM Assets and we will check the outcome.
If I come across such an idea there: It will have my votes.
Regards,
Holger
Hi Monica
With UM assets you have to use repository-based deployment.
For webMethods deployment, we are trying to get away from deploying directly from the run-time servers. Using repository-based deployment is a better idea since the assets are stored and built from a VCS (Version Control System). This also fits in better with DevOps.
To deploy UM assets, the high-level steps are:
- Export assets from UM realm using Enterprise Manager
- e.g. right click on realm in EM and select Export Realm to XML
- Check assets into VCS (optional but a good idea)
- check XML file into VCS
- Build to repository using Asset Build Environment
- in build.properties make sure you set enable.build.UniversalMessaging=true (see Deployer User’s Guide for more info)
- Configure Deployer and create project
- Select Deployment source (repository)
- Map to target(s)
- Deploy
I hope this helps.
Regards
Wayne
Principal Instructor - webMethods product suite
1 Like
Hello Wayne,
this is a very interesting information!
If we have publishable docs in IS and create a trigger with server side filtering, then some corresponding objects are created in UM.
Now, assume that we’ve changed the trigger (changed the filter condition). When we deploy the trigger to a runtime (IS), two things (at least) have to change (in my view):
- The trigger definition in IS
- Something (don’t know exactly what) in UM – since the filtering is done in UM
And now the question: Does your statement about deployment of UM assets mean that by deploying (repository based) only the trigger (as an IS asset) we will NOT change UM to the desired state? I.e. that we also have to explicitly deploy assets of type ‘UM’?
I’ve always assumed that the deployer (here I mean the system component) would change all system components as needed so that everything works after e.g. a trigger (IS asset) has been deployed. But this assumption would be wrong if we have to explicitly deploy UM assets along with the trigger (or some other IS assets, e.g. publishable docs).
The same situation would arise when deploying a process model (and its generated package): the subscription or the transition trigger might have been changed so that UM has to be updated as well. Will it be updated by deploying only the generated package?
Could you please clarify on this?
Thanks a lot!
Hello FML2
If someone builds an IS pub/sub solution (using wM messaging), they will have IS publishable doc(s) using protocol buffer encoding + wM Messaging Trigger(s) + pub/sub service(s). These will be contained within IS package(s).
When they save the IS Doc in Designer and do a “Sync Document”, the IS creates the necessary google protobuf descriptors and the channel that corresponds to the IS doc gets created on UM. The protobuf descriptor gets attached to the channel. This is used by UM for server side filtering.
A wM Messaging Trigger subscribes to the IS doc. The trigger receives messages from the corresponding UM channel. If the trigger uses a Provider Filter, this is created/updated in UM when the trigger is saved in Designer.
So far, so good?
Regarding deployment of a pub/sub solution from IS / UM to a new environment. Deployer can be used to migrate packages containing IS docs, services, triggers, etc……
The deployment of the IS publishable docs (with protocol buffer encoding) using Deployer to the target IS will cause a synchronization of the document with the provider (UM) and this will create the corresponding channels on the target UM. Same as what happens if you manually save/update the IS doc using Designer, except Deployer does it under the covers.
Also, when wM Messaging triggers (with Provider Filter) are deployed (using Deployer) to the target IS, this will also update UM with the provider filter info.
Therefore, using Deployer for IS packages (including IS docs, triggers) will deploy the major pieces of the IS / UM pub/sub solution.
As I mentioned in my earlier reply, UM assets can be extracted from the realm (into XML) and then deployed using Deployer. However these assets are things like realm configuration, ports (interfaces), channels, queues, etc…. These UM realm assets will likely be required for a complete solution but the deployment of the main IS pub/sub components are taken care of by Deployer.
Regards
Wayne
1 Like
Wayne, thank you very much for the clarification!
So, as I assumed, if we deploy a pub/sub solution, everything “should just work” after the deployment has been executed successfully, and there should be no need to deploy UM assets separately.