Hi,
I have a broker created on Dev Env and I have a trigger listening to the broker. When I move to the new Testing environment, the trigger is not listening to the broker I created. Instead, its listening to the local broker(Locally Publishable Documents). In server logs, I see the error message stating “trigger unable to subscribe to the broker”.
The notification is publishing the docs to the broker.But, since the trigger is not listening to the same broker. The documents are not getting picked up.
D0 I need to Syn the docs the first time when I move to the new environment.How would I do that from console??
Yes try to sync up the publishable docs with that corresponding IS/Broker and you will locate the Broker DocumentTypes/sync icon in the Developer tool itself.
If you dont find the icon other ways is click on the publishable documenttypes and in the settings just try to unselect the publishable documents to broker and select it again it will persist to broker as fresh install.
If still problem persists disable and enable the trigger.
RMG,
In our production env, we are not supposed to use Developer. Is there any other way of doing this syn.
I was going through “webMethods Broker Administration Guide” and noticed that the Broker Server configuration and Broker Config information can be exported across different Envs using ADLs. I have never tried this earlier.
Did any one try the ADL approach. Feed-back is appreciated.
Brain,
There are several ways that I know of to do this. One, have your operations folks use the developer to sync the doc types when loading in the package, this is what we do. No problems with that, only they would have login rights not the developer. Second, you can try using the clipboard copy feature available through the broker admin tool. This would require both production broker and the test/staging broker to be available to the same Broker admin tool. You select the document type you want or client and paste it into the other broker. Third, you can use the export/import option to export just the client or documents or both that you need to sync and import them into prod.
I haven’t used the second way but it should work for you if your ops team does not want to use the developer. The third way should work as well but you would have to use the browser based admin tool to be selective about which client and document to export. The command line is all or nothing. And you probably wouldn’t want to do that for each migration. Although you should be able to use the command line tool for the import after you have exported the clients and documents from the admin gui tool.
If your ops folks don’t want to use developer then either of the other two options should work. I would just setup some simple tests to confirm the results are what you want.