Use of Third Party Apps | Pricefx Knowledge Base

This page summarizes topics and issues we need to address when integrating 3rd-party apps into Unity.

The Visual Configuration is a 3rd party app (or apps) and a good candidate to validate the use cases and identify potential issues.

A potential small overlap with Universal iFrame integration has been identified and should be researched. Namely the communication with Unity from the app running in an iFrame can be leveraged in the future.

Feel free to comment and edit the page to add your feedback.

Assumptions

The integration must not assume a particular 3rd-party app being integrated, it has to be oblivious to its internal details
- e.g. it can’t assume that Pricing Strategies Designer is loaded in particular, it has to be completely universal
Unity must provide an API so the integrated app can interact with it, e.g. send notifications
- The Unity and the integrated app can communicate using window.postMessage

Brief summary of the topics

Topic	Priority	Description	State
implemented Solving CORS with 3rd party apps	Must Have	The 3rd-party apps will be hosted separately from Unity where it will be included via iFrame. The app (hosted e.g. on developer.pricefx.eu) needs to make HTTP requests to any Unity cluster/partition (e.g. tmpl.pricefx.eu) and it needs to go through without CORS.	Solved PFUN-15610
Implemented Storing the configurations	Must Have	We need to figure out how to store configuration of the 3rd-party apps so Unity knows about them and is able to display them in an iFrame and provide an entry point in the main menu.	The configuration is stored in Advanced Configuration. PFUN-15610
Partially implemented Configurable entry points	Nice to Have	Unity could provide configurable entry points where the 3rd-party apps will be accessed from, possibly passing some context information to the app (e.g. current quote ID, customer ID and sku). Such entry points can be the main menu or buttons in different screens.	Implemented only menu item for External applications. More use cases TBD PFUN-15610
Not implemented User roles & permissions	Nice to Have	Each app requires some extended permissions to run. It might not be wanted to give those permissions to the user himself. He would only do things the 3rd-party app allows him to do, relying on the app not to abuse it. We need to figure out how to allow 3rd-party apps to perform privileged actions (i.e. admin actions) without allowing the user to make the actions just by himself in the UI or through the REST API.	There is a ticket partially addressing the issue: PFUN-16294
Not implemented Interaction with Unity	Nice to Have	Unity could to provide a way the integrated app interacts with it, e.g. for sending notifications. We can also research possibilities how certain data objects can be shared between Unity and the 3rd-party app in the iFrame for performance reasons.	Real use cases not defined yet.
Not implemented Site reliability	Must Have	Internal apps (such as Pricing Strategy Designer) are hosted on developer.pricefx.eu and we need to make sure the site is not down or the URL doesn’t become invalid. In general, the 3rd-party apps can be hosted anywhere. How can we ensure that the user doesn’t load an empty iFrame when the app is down?	Currently not being addressed.
Not implemented Deployment of internal 3rd-party apps	Must Have	We have to make sure the apps are deployed correctly so the browser recognizes that a version has changed.	Currently not being addressed.

Storing the configuration

Making Unity aware of the app(s)

We need to store somewhere what 3rd party (internal/external) apps are available for Unity to display. The ideal place can be discussed, an obvious candidate for this is the Advanced Configuration.

Each app should have its own unique configuration entry in the Advanced Configuration. Unity could identify such apps by a common prefix, e.g. “third_party_app_<APPNAME>”.

The configuration entry should contain the following information:

name - a unique identifier of the app.
label - the label/description of the app, possibly displayed in the app’s header when it’s loaded into a page
url - the URL loaded in the iFrame

Are there better places to store the configuration in?
What other information do we need to store?

Configurable entry points

Unity needs to know where each app can be opened/accessed from. Unity should provide a list of possible entry points (hooks) where each app can hook itself. E.g.:

Main menu and its sub-menus
List of pricelists
Price list detail
List of quotes
Quote detail
Live Price Grids
LPG detail
…

The app will list the entry points it wants to be accessed from. Each entry point needs to have the following information:

path - an identifier of the entry point provided by Unity, or a list of points forming a path (in a menu and its sub-menus)
label - the label of the menu item/button/etc
tooltip - optional tooltip/help text displayed on/next to the menu item/button/etc

Each entry point comes with some contextual information which can be passed to the app in the iFrame. E.g. when the user is on a Quote detail screen, Unity could pass the quote ID to the app. The app can then render itself properly using this information.

What entry points should we support?

Example configuration

The configuration of the app is a JSON containing the following information:

JSON

{
  "name": "PSPDesigner",
  "label": "Pricing Strategy Designer",
  "url": "https://developer.pricefx.eu/tools/pricing-strategies-blockly-unity/",
  "entryPoints": [
    {
      "path": ["main_menu, "visual_configuration"],
      "label": "Pricing Strategy Designer",
      "tooltip": "Open the Pricing Strategy Designer"
    },
    {
      "path": "pricelists",
      "label": "Open Strategy Designer",
      "tooltip": "Open the Pricing Strategy Designer",
    }
  ]
}

User roles and permissions

The 3rd party app is usually logged in using the Unity’s session, i.e. the same user. However, the app might need to perform some actions for which the user doesn’t have permissions. For example, the app can modify a PP table which the user normally doesn’t have access to.

Possible solutions
Manually assign the app’s required permissions to the users.
✅ Pros	❌ Cons
No extra implementation needed	Admin would need to know what permissions to assign Manual process, lots of overhead for partition admins Possible errors if not all permissions are assigned User would be able to perform actions he’s normally not supposed to perform
Create a business role for each integrated app. Unity would know from the apps' configuration which business roles are used for this purpose and would hide the corresponding UI actions/controls from the user.
✅ Pros	❌ Cons
Creation of the roles can be automated, e.g. via Platform manager when deploying an accelerator Unity would need to contain extra logic for determining if a UI component/control should be visible or not	User would still be able to perform actions he’s normally not supposed to perform, but only on the REST API level. The UI would hide the controls.
Implement some kind of “On behalf of” actions. The app would have the required privileges automatically and would perform the actions on behalf of the logged in user.
✅ Pros	❌ Cons
Probably cleanest solution	Complex Involves work both on front-end and back-end Trust issues with the 3rd party apps. This might be misused by the app.

What other possible solutions can we come up with?

Interaction with Unity

The app needs to be able to communicate with the parent Unity front-end and vice versa. There are two extremes and we need to find balance between them:

Independent - the 3rd party app does everything itself (login, API calls), it just receives the information about the currently logged in user, or it can share the session with Unity
Dependent - the 3rd party app does everything through Unity, including all the REST calls. The benefit of this is questionable.
Balanced - Unity can share some data/information with the 3rd party app

What direction should we go? What information does it make sense to share between Unity and 3rd-party app in the iFrame?