Here are a few comments/observations on the new 9x versions of webMethods ,based on recent upgrade experience.Please add your own as comments or if you see a better way of doing it.
1. Designer-Since webmethods has deprecated Developer(RIP old friend) totally ,anyone who moved directly from developer to designer in 9x directly may see themselves hopelessly disoriented.(Unless you had the foresight to switch to Designer from 8x itself)
Here are a few Designer related observations/Tips
Arrange your designer windows to mimic the erstwhile Developer to minimize heartburn. This is especially useful while debugging where the default designer windows can really have you pulling out your hair(In my case ,teeth ,since I have precious little hair left)
There is no "Trace to Here" feature in Designer .However we can use the base eclipse breakpoint feature to trace code
Set up breakpoints by doubleclicking on the extreme left of the code line(The breakpoint will display as a red dot)
Use the F8 shortcut to trace to a preset breakpoint
See attachments for screenshots
2. IS instances-We can now spin up as many instances of integration server as we want without having to install the whole shebang from the start. This is especially useful while patching the environment. Since all our components like IS ,MWS and Broker can now reside in one root folder with common shared components.
The only component where they have not provided this feature is OFP where we have to install an OFP for each IS separately. Hopefully next release will fix this.
3. Resubmit button for Process instance-This is one thing that SAG messed up with in 98.There is no multi resubmit button for Process Models. Now each resubmit needs to be done from within the instances ,Meaning more clicks and wastage of time and support costs when we have to resubmit process instances in bulk.
Hopefully SAG will add this in future releases. Maybe we can all put in a feature requests to include that again so that SAG sits up and listens
Till then, we probably have to write a service to resubmit Process instances in bulk and possibly write a CAF front end for it
4. SFTP Support: With 9x ,webMethods has provided supporting services for sftp operations, which is neat. It uses jsch apis to do its business(which we were already using with custom java services to connect to sftp clients).Nevertheless its good to have out of the box services provided by SAG for SFTP.
The implementation involves setting up of aliases for the sftp server and users,which is nice as we can verify the credentials are working beforehand rather than waiting for an integration to fail.
What's missing ,however, is the ability to create sftp ports so that external clients can connect to webMethods. Probably enough feature requests to SAG can move them to add it in the next iteration.
5. Trust Store for Enterprise Profile in TN-We can no longer simply add certificates and Private keys to our enterprise profile. Now we need to configure a trust store and configure it in the Enterprise Profile Certificate tab.
However if you use the Database migration utility ,It automatically migrates all the certificates in the Enterprise Profile and the subsequent behavior is like any other profile.
6. Terracotta-The Jury is still out on the verdict on Terracotta. From what ive seen it’s a bit of extra work to set up the terracotta servers, however once I got the hang of it and its future possibilities ,it sort of grew on me.
Heap space was one off the biggest limiting factors while writing and designing integrations in webMethods in the past. We used to write elaborate logic to keep the memory utilization low or risk crashing the server.
With Terracotta taking giving us the capability to handle higher heaps outside the IS wtithout risking its integrity ,gives us the flexibility to dumb down our integrations and deal with Volume purely at the Administration level.
Also this opens the gate for future big data endeavors.
But its too soon to say as there may be a few kinks they might need to smooth out before its smooth sailing.
7. Universal Messaging-With Broker going out of support in 2020,nows the time to start evaluating UM and formulating a plan for implementation. The 9.9 readme mentions something about a direct movement from Broker to UM, but cannot comment as I haven't tried it.
But UM has license cost so this might be the best time to evaluate if you want to stick to SAG or get a cheaper messaging solution.
hi Varghese, please do write feature requests - that’s very helpful feedback for the Product Managers. Your (3) below is one to submit. The way to do it is through Brainstorm on the Empower web site.
As for migrating from Broker to UM, you can see the procedure for that in the guide Migrating from webM Broker to Universal Messaging, also available on the Empower web site, in the Documentation section.
I am on v9.8 and the Breakpoint will display as a light blue dot. And also its useful to have Breakpoints tab before the Variables tab. By default its there (top right section) and no customization is required but just remove Outline tab (middle right section).
I can also set multiple Breakpoints for my flow and the Breakpoints tab will show all of it.
@Mahesh:Yes blue dot(Must be going color blind too).I checked out the Breakpoints tab and its useful to know where all the breakpoints at.
But since the designer in debug mode only has 3 “Active” windows(Top left,top right and bottom pane).I really wouldnt sacrifice one of them to display static data.
But Ive added it to next to my variables pane to look at when I need it.Thanks for the info.
Build-In SFTP has been introduced with wM 9.5 SP1.
I am not sure if SFTP-Ports are possible, but it might be worth to post a feature request in brainstorm for that.
Latest Release for Broker is wM 9.6, but it can be used with all Versions wM 9.6 and newer.
“Trace To Here” will be back in one of the upcoming releases (not sure if it already made it into wM 9.9) as far as I understood.
Having the possibility to create several instances from one installation directory is dependent on how you want them to operate resp. being patched. There might be reasons to have the possibility to patch them independently i.e. for avoiding data loss. If Broker and IS are stopped in parallel, the data in the IS which has not been transferred to the Broker is lost upon IS restart. Therefore patching the Broker independently from the IS might be an option to avoid that. Additionally patching components separately makes it easier when you have limited time frames on production for doing so. From my experiences with wM 9.5 SP1 the patching for one component varies between approx. 30 minutes (Broker) and nearly 120 minutes (MWS when applying Core Fix) dependent on the type of Fixes being applied (Bundle-Fixes for UM, CentraSite, OSGI, WSS take quite some time where as Fixes for SharedComponents or Broker JavaAPI are applied very fast.). When patching all components together these Bundle-Fixes only need to be applied once, but in total this might take longer as you are allowed to by your operations team.
Re your comment about patching components independently—
Wouldn’t all guaranteed docs remain on the IS till delivered to broker?
In any case my comment was more about common components in a Fix.
Lets examine a case where we have separate installation for IS,Broker and MWS:
We apply an IS Fix that has got common components, then the common components would need to be manually installed in the Broker,MWS(The Fix readmes generally advise on the need to install manually but sometimes its vague).
On the other hand if all are components are in the same folder,then the common components updates would automatically apply to the other components.
I seen situations in the past where we had separate installations and we ‘missed’ applying the common component on the Broker and we saw weird issues which took hours of effort and tickets with SAG to figure out and resolve.
Further,in the above situation ,if an IS fix needs a manual installation on the Broker.Bringing up the application without the Broker Patch in the interest of time may yield unexpected results as the common component versions in Broker and IS differ.
I would rather buy that much more time from the Business to patch the environment correctly
As always, the optimum implementation for each customer my vary based on constraints put on it by the business team.
As far as Im concerned ,Im really excited about this feature as it really cuts down the time and effort needed to patch environments.
We have quite a few ISs per environment,and in the past ,we had to patch them individually,then figure out all the common components,write scripts to move the jars manually to the other components like Broker and MWS.
Basically a lot of detailed “Busy Work” that will hopefully be avoided now.
as far as I understood only as long as the IS is up and running while Broker bounces.
If IS gets bounced while Broker is down this might not be the case.
When using UpdateManager to apply Fixes there should not be a need to copy the jars manually by script.
It should suffice to apply the affected Fixes in a separate run of UpdateManager using the same image.
This ensures that all installations gets the Fixes applied they really need.
In my 9.5 environments I have not observed any issues relating to common components version mismatch.
But they are not clustered. In clustered environments all nodes being part of the cluster should have the same versions applied.
I agree that the environments differ from customer to customer and the same applies for the patching strategy.
This is also a matter of Multi-Tier architectures where the transport layer (Broker/UM) has to be separated from the integration layer (IS, Optimize) has to be separated from the presentation layer (MWS) for security reasons.
Nothing from SAG on point 3…We have developers working on a custom Resubmit solutioin using webMethods APIs from IS
In case SAG does not provide solution
THe ideal solution would be a wrapper CAF page that would mimic the process Instances Page that SAG MWS provides ,but which will have the Resubmit button
What we would need is some nifty CAF development and some back end IS support.
We could even pool resources online to build an open source community solution for this problem
Just an idea…not sure of the legalities involved.
