Messages and Notifications in JDE Orchestrator
Being able to send notifications and messages in JDE through the Orchestrator is very helpful when you need one or more users to know what’s happening in JD Edwards.
Both are communication tools, but why are these two separate functions? When should you use messages and when is it better to use notifications?
Here is a quick and easy way to understand the difference between the two.
What Is a Message?
A message is added as a step inside the orchestration. It is a sub-component that is executed every time that particular orchestration runs. When it is triggered, it sends a message about a specific action inside that orchestration (such as a step that failed).
When to Use Messages:
Messages are specifically correlated with an orchestration and are very useful when an immediate review or action is required from a specific user.
What Is a Notification?
A notification is a master component that works within the Orchestrator at the same level as the orchestrations. Users can define what inputs will be passed into these notifications when they subscribe to them, and they run automatically.
When to Use Notifications:
Notifications are intended for large groups and are used to monitor what is happening in JDE as a whole. They are very versatile for managing communication workflows for a subscriber base with varied assigned tasks (such as different accounting groups).
Note: Messages and Notifications can be sent to users inside or outside JDE. Simply choose the email address for the recipient. Notification lists are only accessible in JDE.
Quick Example of Messages vs. Notifications
Let’s say you have a single user tracking exchange rates. You could build the messaging feature into the orchestration as a sub-component to update that user on whether or not the orchestration was able to retrieve updated exchange rates for the day. If you have a globally distributed team tracking different currency pairs, you would want to set up a master level notification instead, allowing recipients to subscribe to the updates that are specific to them.
These are general best practices and NOT hard and fast rules. Sometimes, you can accomplish the same thing with a message or a notification. Then, it’s just a matter of figuring out which one is the easiest for your team to build and use.
Understanding Notifications in the Orchestrator
Notifications have a subscription framework. Users can create and publish notifications, and other users can choose to subscribe or not. Users do this by going to “my subscriptions”, finding the appropriate notification, and subscribing. A manager can also assign a notification to a direct report.
Subscribers can define their own inputs giving them control over exactly what they want to see and preventing clutter in their inbox. For example, notification subscriptions might be tailored based on work processes, roles, company, or business unit. This means the same notification might be used by the entire organization, different groups, or individual users. Because a single notification can be “sliced and diced” in so many ways to serve multiple subscriber groups, it is a very powerful communication tool.
Notification Example: A user might be notified to approve and post unposted journal entries for which they are the approver.
Customer Use Case for Messaging
One of our customers wanted a message to go out to the correct person when a PO was created and needed to be approved by a manager. Each PO could have a different approval route depending on the order type, dollar amount, and other criteria. They wanted this to be done in real-time upon entry of the PO since delays in the workflow could lead to problems with inventory.
Step by Step Build
- We created a data request to look up the approver, based on order type, PO Amount and Approval Route code.
- Then we looked up the email address of the approver using a second data request from the who’s who email table.
- Next we created an email message to the approver’s email with a link to the PO approval screen.
- Finally, we put this all together with a form extension that calls the orchestration whenever a new PO is entered to automate the approval notice.
Now they have real-time workflow from inside a single orchestration. It took about an hour to create, including walking the client through the whole process so they understand how to build their own in the future.
Want to get help with using messages and notifications to enhance your workflows? Contact us for consulting help.