Created Web applications should be published in App Manager for users to start using them.
Introduction to application approval process
The application (app) approval process involves all the states in an application life cycle from creation to retirement. The user's actions will be restricted based on the permissions that have been assigned to them. The following topics illustrate the application approval process:
Application approval process action definitions
The actions that can be carried out in the application approval process are defined as follows:
| Action | Definition |
|---|---|
| Submit | The user can submit newly created mobile apps to be reviewed. |
| Approve | The reviewer will approve mobile apps that pass the review process. |
| Rejected | The reviewer will reject mobile apps that fail the review process. |
| Publish | The publisher can publish mobile apps that are approved. All published mobile apps are visible in the Store. |
| Unpublish | If needed, the publisher can unpublish mobile apps. Unpublished mobile apps are temporarily removed from the Store, but are supported by App Manager. Furthermore, these apps can be re-published to the Store whenever needed. |
| Depreciate | The publisher can deprecate mobile apps. All deprecated apps will be automatically removed from the Store, to stop all new installations. However, these mobile apps will be supported by App Manager. |
| Retire | The publisher will retire mobile apps, and such apps will not be supported by App Manager in the future. In such instances, all retired apps will be automatically removed from the Store, to stop all new installations. |
Application approval process based on user roles
The transitions in the app approval process, together with the permissions needed at each state are listed as follows:
| Transition Process | Allowed Roles | Allowed Actions |
|---|---|---|
| Creating a new app | Administrator Internal/Publisher | |
| Submitting newly created apps | Administrator | Submit |
| Reviewing submitted apps | Administrator Internal/Review | Approve Reject |
| Publishing approved apps | Administrator Internal/Publisher | Publish |
| Re-submitting rejected apps | Administrator Internal/Publisher | Submit |
| Unpublishing published apps | Administrator Internal/Publisher | Unpublish |
| Re-publishing unpublished apps | Administrator Internal/Publisher | Publish |
| Deprecating unpublished apps | Administrator Internal/Publisher | Deprecate |
| Deprecating published apps | Administrator Internal/Publisher | Deprecate |
| Retiring deprecated apps | Administrator Internal/Publisher | Retire |
Promoting web application to published state
After adding the web application to the publisher, you need to promote its lifecycle state to published state, to publish it as follows.
Once a web application is added to App Manager, it is added to the registry as an asset, and a lifecycle is attached to the web application. The lifecycle state for a newly created web application is 'Created'. Users can change the state to 'In-Review', which will automatically initialize a work flow event. Work flows will be explained in another section. Once an admin user approves the work flow event, then lifecycle state moves to the 'Published' state and will appear in the store for users to consume. This behavior can be extended according to the user requirement with the provided extension points.
Once a web application reaches the 'Published' state, an API resource will be created under <PRODUCT_HOME>/repository/deployment/server/synapse-configs/default/api/ directory. Name of the file will be {web app created user}–{web app name}_v{version}.xml. This is the REST endpoint, which will be invoked once the gateway URL is accessed.
After promoting the lifecycle state of the added web application, you need to configure security for it. For information on configuring security for web applications, see Securing with SAML2 SSO.