Designing Notif. Download Profiles
A notification download profile controls how the system routes notifications to third parties. You associate a notification download profile with one or more service providers. Whenever a notification is sent to a service provider, the system uses the notification download profile to determine the interface method and the format of notifications.
Note:
A notification download profile corresponds with a protocol used to route notifications to service providers. If you electronically route all notifications using the same protocol (for example, all service providers in a given jurisdiction may conform to the same record formatting and routing method), you will have a single notification download profile. If you have to route notifications using different protocols to different providers, you will need one notification download profile per protocol.
Using the notification download profile, you can define which outgoing messages are sent as an XML document via the XAI tool and which are sent in batch format. When a message is designated as being sent via the XAI tool, then you typically define XAI routing information. If a message is designated as being sent via batch, then you must indicate the formatting algorithm used by the extract program.
Note:
XAI Routing Information Optional. You may indicate that the message should be routed via XAI, but enter no XAI Routing information. You may do this when you are interfacing with one of your own external systems and where the system may be accessed directly. In this scenario, you are using the XAI functionality to communicate between systems using XML documents, but you don't need the routing logic within XAI. Refer to
An NDS Message That Doesn't Require Routing for more information.
The easiest way to design a notification download profile is to choose a representative service provider and design a notification download profile for it by filling in the following matrix. After you've designed a profile, determine how many other service providers can use it. Then design the next service provider's profile and determine who can reuse it. Repeat this process until all your service providers have a profile. Once the profiles are designed, you're ready to set up the control tables.
Background Process used for batch messages | Notification Download Type | Processing Method | XAI Route Type | Format Method |
File Transfer | Inform all parties that customer is stopping service | Batch | | Format Stop |
| Inform all parties that meter has been changed | XAI | Meter Change | |
| Send consumption history | Batch | | Format Consumption |
| Check if it's OK to switch customer from current supplier | XAI | Confirm Switch | |
| Reject request | XAI | Reject | |
Notice that you define the background process at the profile level, but you indicate for each download type whether it will be processed via batch or via XAI. If at least one of the processing methods is batch, then a background process must be entered, otherwise it's not applicable.
Also note that it is possible to link more than one XAI route type to each notification download type formatting method. However, this is not recommended if you expect an
asynchronous response to the NDS message.
After you've designed notification download profiles to cover every protocol, you are ready to set up the control tables.
Fastpath:
Parent topic