I’m working on publishing a Portal, and I’m seeing this warning:
Incompatible plug-in(s) detected. Refactor the portal object precedents to only use plug-ins compatible with portals. Using incompatible plug-ins can cause the published portal to error. Precedent(s) containing incompatible plug-in(s).
Has anyone dealt with this before?
What are the recommended alternatives for Excel Tools functions (like reading/writing Excel, parsing uploaded files, or exporting data) that work in Portals?
Are there any Appian-native approaches or other supported plug-ins I can use instead?
Would shifting the Excel logic into a process model (triggered from the Portal) be a valid workaround?
Any best practices or migration tips would be greatly appreciated.
Discussion posts and replies are publicly visible
The appian-native approach you would need to consider is a Web API and/or a Start Process call, and in either case you would configure it such that it launches a process model, which can then utilize whatever plug-in (or other smart services) you want, then pass the result back to the Portal form.
Hey — thanks for raising this. I ran into the same limitation.
You can work around it by moving the excel-logic out of the portal itself. for example, have a web api or process model that handles reading/writing/parsing the excel, then the portal just talks to that service. that way the portal stays clean of incompatible plug-ins.
If you want, I can sketch what that architecture looks like, or help you pick plug-ins or smart-services that play nicely with portals.
That would be great a sketch of the architecture flow would help a lot. And yes, a shortlist of portal-safe plug-ins/smart services would be super useful too. That way I can see how the pieces fit together and know which components I can safely use without running into compatibility issues again.
Manikanta009 said:Would shifting the Excel logic into a process model (triggered from the Portal) be a valid workaround?
Yes! Create a process model to handle the excel functionalities and call the process model using start process or web api from the portal!
Moving to a process model and calling it from the portal is the standard workaround for this incompatibility.