I am new to the webMethods, just doing a basic operation. I have list of Packages on my colleague’s windows machine (IS 10.1). He can login to web IS console using Administrator user and able to see listed flow services while navigating to (Packages > Management > XYZPackage) of any package.
But once I copy the same packages from his environment and paste to my local Windows (IS 10.1) location (C:\SoftwareAG\IntegrationServer\instances\default\packages), after restart, using IS web console ((Packages > Management > XYZPackage > Services), I can see the copied packages but unable to see any services of any package, which we can see on his environment, using the same Administrator user. Need your help please.
I am able to find the Packages > Management > Install Inbound Releases option
, however; I am unable to find the Packages->Management->Export Package
In the IS 10.1 even though, I logging in a Administrator.
is there anything in the server.log during loading the packages, eventually loading in wrong order?
Did you try to restart the IntegrationServer after placing the packages in the directory?
The “Export Package” ist not in the list of the links above the table, but it is located inside the table affecting only one package per row in the table.
Thank you all of you and I have high respect of the ccommunity.
So yes there were few issues.
1- Copy paste the package sometime not works and reason as Yogesh mentioned was mainly that by export it out and importing in goes through the validation process.
2- During the above step I found that my JVM version was lower than from where I was coping from, which I corrected and I wish it would have been as simple as updating you JAVA_HOME. But after this package importaed successfully.
3- Once observed the server logs as suggested by Holger, I found that the Umserver configuration required which I did but right after this my Trigger started failing.
4- So I found that once you copied the Package having Trigger required the Sync of the Document. Which can be done via Designer.
I wish webMethod be more intelligent as the Sync operation can be perfored automatically during import secondly the JVM should be driven by JAVA_HOME rather than changing many places such as Extended watt configiration and Java Exec to get it working.
you might want to consider to check for Deployer to transport packages from one IS to another.
Deployer will also take care of dependency checks as well as syncing DocTypes after deployment.
Importing a package is just part of deployment, besides of document type synchronization, don’t be surprised it won’t help you to synchronize ACL or setup scheduler, because it’s not designed to do so. The official way to deploy a package is Deployer, since it doesn’t work in your case, don’t blame it’s not intelligent enough.
Multiple webMethods instances could be installed on one server, and they could rely on different version of JVM. That’s why you will need individual extended setting to specify it, instead of one single JAVA_HOME environment variable.
Just for my understanding, does Deployer also Sync the Publishable Documents to UM apart from the ACL, Schedulers and Adpaters may be?
I can find only one JVM folder on my windows C:\SoftwareAG\jvm
So can you install as many JVMs on your machine and for every My Webmethod Server you can have different watt configurations?
Lastly what Architectural Requirement would it be for us to decide, lets have another webMethod instance running on different JVM adn still it will work gracely within a cluster environment.
Deployer could help to sync Publishable Document Type to Broker/UM, and sync scheduler services in database, and sync ACLs in file system if the deployment task is built properly.
By default, webMethods always has a build-in JVM. But you could install other JVM on server, and change the watt settings to use external JVM.
I didn’t see many cases to user external JVM. The only reason is probably you are looking for the better security provided by higher version JVM, and in the meantime you will have to work with old version webMethods.
in this case, build the Deployment Project on the Source Environment and export the final build.
Then transport this build to the target environment and import it to Deployer.
Map the different Sets in the Project to the right targets, create deployment candidates and deploy them.
