Hi Team,
We have requirement like to setup around 200 SAP Listener notifications. When we are migrating from Test to production, its consuming more time to create same setup with Production sender and receiver id’s.
Is there any method to deploy with production sender and receiver ID’s. Or do we have any option/service to read sender, receiver and message type from XML/Flat file and create SAP Listener notification.
Can you please share, if you have implemented any simple approach for this type of Scenario.
Thanks,
Raghu
Hi Raghu,
can you explain where you configure sender, receiver and message type inside the listener notification?
Is this related to IDoc processing or pure RFC processing?
As far as I can tell the listener notifications do not have any environment specific settings except for the reference to the listener.
Regards,
Holger
Hi Hogler,
To setup SAP routing listner notification by updating Sender, Receiver and Message types in webMethods notification setup to receive Idoc from SAP using tRFC call.
Thanks,
Raghu
Hi Raghu,
we are not using Routing Listener and Routing Listener Notifications in our project.
We are only using regular IDoc and RFC Listener Notifications and ALE:OutboundProcess for IDocs and regular adapter services to invoke RFCs on our partner systems.
Are you using Deployer?
If so, you might have the possibility to perform a variable substitution here when defining the map for the target.
This map can be exported and reused by the next deployment project for the same type.
In this case you will define the substitution once and then it will hopefully transform the routing listener notifications to the new values.
Regards,
Holger
Hi Holger,
When we use Deployer to migrate SAP Listener Routing notification, it will be migrated with same Test Sender, Receiver and message type values. Again we need to update the these 3 values in production environment. We have to 2 production nodes. we have to do the same updating activity in both nodes.
So, we are checking possible solution for this type deployment.
Thanks,
Raghu
Hi Raghu,
from your post I assume that message types differ between test and production for one and the same routing notification.
It might be a good idea to ask the sender and receiver systems to use the same message types for test and production.
This would eliminate at least one of the fields.
For ther other two (sender and receiver) you might want to consider the following approach.
It sounds a bit complicated, but it should do the trick when you run it after deployment of the notifications.
Create some sort of lookup table (either database or xml-file) with the following fields:
Name of Routing Notification; target sender; target receiver(; target message type)
- Read the node.ndf for the notification as a file from OS (replace dots and colons to slashes and add “packages/PackageName/ns/” in front of it.
- convert to xml-document and check if the required fields are in it
- if so you replace them directly
- if not, you will have to decode the base64-coded field to an xml-structure and you should find the fields in there to replace them.
Now go the same way backwards:
- encode the propertey to base64
- put in the xml-structure fo the node.ndf
- write the node.ndf back to OS.
- Reload the package(s) afterwards to make IS aware of the changes
Unfortunately there is no service in WmART which do so by it own.
Regards,
Holger
Hi Holger,
Thank you for on top of it.
I believe editing node.ndf files and reloading packages in production is not correct approach for this kind of development work.
MessageType would be same in test and production. Even if we use deployer also we have to update the Sender and Receiver field values manually.
We are thinking like, Once create notifications in test then will put Sender, receiver, msgType and Notification name in the excel/delimited flat file.
then write a service to read this file then Looping on each record and using updateListenerNotificationNode service to update the values in Production.
Still, for this one also need to put some manual effort to capture all notification details and also it may create some human errors.
So checking in the forum, for better possible solutions.
Thanks,
Raghu
Hi Raghu,
as wm.art.dev.notification:updateListenerNotificationNode is not a public service use this service with caution.
But even when using updateListenerNotificationNode, you might need to reload the packages after updating the nodes.
Regards,
Holger
Hi Holger,
Thank you,
For Adapter Notification, there is an option “reload the values from the adapter” after updating the nodes, package reload is not required.
Please advise, if there is any other option to do it in webMethods.
Thanks,
Raghu
Hi Raghu,
I am not sure if this function will update these fields also in your case.
Did you check Service Development Help for further advise on this?
How often will the notifications be updated so they need to be transported from test to production?
If this a create once, never touch operation you should separate them from code being delivered regularly due to functional changes.
On the other side, you can consider using regular listening notifications for each system you are receiving messages from and send the by sendIDoc or ALE:OutboundProcess to the receiver using a 1:1-mapping for transformation.
Ideally there should be some data in EDI_DC40 IDoc Header representing sender and desired receiver, which will help you to route the IDoc in IS instead of using routing notifications.
Regards,
Holger
