Disclaimer:  This information is provided based on my testing and is current as of version 2017.1.2920. Your mileage may vary.  This is an attempt to give actionable information about considerations for DynaChange Rules when working between clients.

If you have been following the development of Prophet 21 this year, then you already know that the web-enabled client for Prophet 21 is the big story for 2017. Epicor is putting significant time and resources into getting this up and running. As of version 2017.1, Prophet 21’s UI can be accessed in 3 ways:

1. The classic desktop UI that you are used to.  This is delivered either via local install on your workstation (fat client) or some version of virtualization (RDP, Citrix, etc) in a thin client model.
2. The Hybrid Client – This is the web client with a Chromium-based browser wrapped around it.
3. The Web Client – This is access to Prophet 21 via a URL in your browser of choice.

This presents a new and unique challenge to administrators of the Epicor Prophet 21 ERP system. Business Rules now need to be able to function across multiple platforms.  The official word from Epicor is that DynaChange rules for the desktop client will work on the web client unless you are popping up a windows form.  I would say that based on my testing so far, this is mostly accurate, but there are some additional things to keep in mind.

General Information

Note: When I reference the middleware server, I am assuming you will run the Prophet 21 middleware and web applications on the same server.  When I reference the web client for this article, I am speaking about both the web and hybrid clients.

Running the web and hybrid client requires that you dedicate at least one server to run the middleware and web applications software. These two pieces of software can run on the same machine.  The middleware is the API that the web applications will access to move data from the database to the user interface and back. The middleware is a big application, on par with the classic desktop client.  By contrast, the web application software is very lightweight, and will not be a significant burden on server resources.

When you install the Prophet 21 middleware and web applications software, you need to keep in mind that system settings apply to the web client just like the desktop client.  This is especially important to remember for DynaChange Rules.  There is a single system setting for the Rules path, normally something like C:\Program Files(x86)\Activant\DynachangeRules\.  You will need to replicate that path structure on your middleware server and put your rules in it.

Start Planning Ahead Now…

Although still supported by Epicor, I do not recommend continuing for too long with the .NET 3.5 DynaChange rules using the Activant.P21.Extensions reference.  You need to bite the bullet and start upgrading your rules to the P21. Extensions reference now.  Take this variable out of the equation now and in the future.  It just makes sense to fix this stuff now.

One final general note, as of this build (2920), there is no Epicor-provided way to determine if you are connecting from the web client or the classic desktop client.  The last update I heard from Epicor is that there is a plan to add this.  I do not know when the release date for this feature is.

DynaChange Rules and SQL Connections

This was an early source of frustration for me when I first started testing Prophet 21.  Though I have not been able to confirm it, I have heard rumblings that your SQL Server authentication mode can affect the interaction of DynaChange rules, the middleware, and the database.  Personally, my configuration runs in mixed authentication mode, so my comments apply to that mode.

What I have come to learn is that when using either Windows authentication (SSPI) or the embedded P21 SQL connection in DynaChange rules, the middleware attempts to connect to the database using the local system account for the middleware server.  This throws an error anytime you fire a rule in the web client that tries to access the database.  A screenshot of this error is shown here.

The only surefire fix I have found thus far is to hardcode a SQL connection into the rule.  I ended up creating a dedicated SQL user for business rule execution.  It is in all of my rules for database connection.  One of the concerns I have is that update queries that trigger an audit trail record will be entered as this user instead of the person doing it.  This could cause an issue in tracing back who did what.  If this becomes a problem for your application, it might make sense to code an additional audit trail entry into your rule.  This would allow you to create a record that reflects who the user was.

DynaChange Rules and Message Boxes

If you are using the Windows forms message box in your DynaChange rules to pop up a notification to your user, this is going to have to be reworked for the web client.  Since it is a web application, these functions and libraries are not available to the web client.  If you try to fire a rule that calls a message box popup or another form, you will get an error that looks like the screenshot.

If you are simply throwing up a message box with an OK button in the desktop client, I would recommend changing this to putting the message box text into the Rule. Message property of the Rule class.  This will send your message to the desktop client in the form of a message box (albeit with a boilerplate window title).  It will also work in the web client in the form of a notification in the upper right corner.  An example of these two notifications is below:

Rule Message from Web Client

Rule Message From Desktop

While this solution is serviceable, there is one issue that I can see.  A desktop message box requires the user to interact.  It also pops up in the middle of the screen, directly in the user’s line of sight.  The web client notification happens in the upper right corner.  It also automatically goes away after about seven seconds, with no requirement for user action.  Depending on your desire to affect user behavior, this may be something to consider.  I have not yet seen the version 2017 documentation update for DynaChange rules.  Hopefully, more of these issues and other related tasks will be addressed there.

Key Takeaways for DynaChange Rules

These are just a few considerations based on early testing of DynaChange rules.  Again this is very early in the process.  I am sure I will have to update this post as we get farther into the process.  The main points to remember are:

1. Make sure you have a rules path on your middleware server that matches the Prophet 21 system setting
2. If you have not started moving off the .NET 3.5 rule library, now is a good time to get that going.
3. You cannot yet tell if you are accessing the rule from the web client or desktop client, but that feature is in the works.
4. You might have to use a hard-coded SQL authentication connection to your database.  Plan for audit trail if applicable.
5. For message boxes, use the Rule. Message property for cross-platform compatibility.
6. I don’t have an answer yet for popping up other forms, but I am working on it and will post when I know

Good luck getting your web client DynaChange rules testing and implementation running.  It is new and exciting, but as with all major changes, there is a learning curve.  Hopefully, we can learn it together and have great success making the transition.

For more on Prophet 21, click here.