Hi, Currently our architecture is as follow: 4 IS’s running on two different physical boxes configured with One Broker and One Database. They are not in Cluster.When ever I install new EDI Document types (for e.g x12 4030/4060 210). Our standard is to promote the packages on all the 4 IS’s but turn the scheduler on only one instance as a part of it we are installing the EDI Document types on all IS’s. Eventually, I am going to each IS Admin page and clicking on the EDI link I am installing Document types.We are actually encountering an issue, the document types are not getting installed properly meaning, some how the Format services are getting messed up in the dictionary pointing to the wrong/different format services and causing an issue for the partner displaying wrong values.But they are getting installed properly on the first instance. Like I mentioned above, all the IS’s are connecting to the same database, when I install EDI document type, it is already there from the database point of view.But according to our standards we need to promote it to all 4 IS’s. I am just wondering am I missing anything while installing the EDI Document types Or am I doing wrong in installing the document types? I also opened the ticket with wMSupport, but they are coming back and saying some one is manually changing the values in the dictionary which we are not in this scenario. Could any one please advise when you get a chance. Thanks, Capri_lak.
Once you install required EDI doctypes on one IS EDIHome…then you can deploy/sync up same WmEDIForTN Package to other 3 IS’s to avoid the dictionary conflict…
HTH,
RMG
Hi RMG, Thank you very much for your response. I am just wondering when you mentioned sync is it an different approach or Do we need to use deployer, to deploy the WmEDIForTN package from test environment to Production environment or Do we need to copy the WmEDIForTN from instance 1 to rest of all the instances? Thanks, Capri_lak.
you can use deployer (depends on your deployment strategy) or do a manual install (replicate/Inbound) standalone to other IS instances/env’s.so this package will be in sync across.
HTH,
RMg
Hi RMG, Sure.I will definitely follow this route to avoid the dictionary conflicts moving forward.One quick thing, when we do manual install (replicate/Inbound), Do we need to restart the servers for the new package to take effect. I mean is it mandatory to restart the servers? Thanks for all your help, Capri_lak.
No need for restart…Just make sure package gets loaded with no errors and enabled.
Packages —> Management page.
HTH,
RMg
Hi RMG, Sounds Good.I am just wondering is it suggestible approach to move the Wm packages from one environment to other(just curious). Also If I am not wrong, when we manually install custom developed packages between different environments we do not need a restart right? Also If I just modify a flow service in the custom developed package, I can also manually install the package through replicate/inbound and restart is not required, even though I am overwriting the existing package with a modified flow service. Could you please advise. Thanks, Capri_lak.
wM advises against using Deployer to deploy wM components. They recommend using the installer to make sure dependencies are managed correctly.
I would say best practice always prefer use wM Deployer tool for custom packages/flow service modifications (release as patch)/TN components/other artifacts etc… migrating to diff environments.But note not the wM provided standard installed IS packages.
But here I am saying manual install for the wM provided package WmEDIForTN overwrite it as you raised the issue originally.
HTH,
RMG
Hi RMG/reamon Thank you very much for all your help. It cleared lot of confusion around the issue i was facing. Thanks, Capri_lak.