How to Publish a LiveCompare App and Best Practices for Maintaining Apps

We recently hosted an online super users group (SUG) event where Brent presented a session on how to publish an app.

In this example we’ve built a workflow we’ve called “Users Premier League” after its function to output the top N users based on the transactions and programs they use in a PRD SAP system.

Premier League of Users Workflow

Here’s the workflow:

It produces a dashboard of the top N users (by executed transaction and program) and collects the rest into a group called ‘Other’:

The workflow is ideally suited for publishing as an app: lots of people are interested in the Users Premier League across the many PRD SAP systems that we run and I’d rather they ran it for themselves than come and ask me to do it every time. After all, LiveCompare apps were designed to democratize access to useful SAP application information.

Best Practice #1: Separate the app interface from the analysis

An app’s interface is its inputs and outputs. In this case we want the user to select the SAP system and get access to the dashboard URL. The rest of the workflow is pure analysis.

To separate the workflow first use the Copy Here short-cut menu command to create two copies of the workflow:

By convention we always call the top-level app workflow: App Driver. I called the analysis workflow: Analysis. Let’s edit the analysis workflow first:

I removed the RFC Destination and the action to read performance history data leaving the input User Statistics dataset. At the bottom I removed all the actions and datasets involved in creating the output report.

Now let’s edit the App Driver workflow:

And after a bit of clean-up:

I left a spot for the Run Workflow action that will call the Analysis workflow:

I associate (or bind) the action to the workflow using the Bind Workflow command from the action’s short-cut menu:

Note: this screenshot is taken from the upcoming 3.5.0 release of LiveCompare where we’ve added support for shared workflow in the Workflow Library and Templates. The dialog shows the name and origin of the bindable workflows. I’ve chosen the Analysis workflow that’s in the same workspace as the App Driver workflow. I click Next:

And choose the input and output parameters. I click Next and then Finish to complete the workflow.

All that remains is for me to write up the action to the datasets in the App Driver workflow:

I run the workflow to make sure it works OK.

Publishing an App

Choose Register an App from the workflow’s context menu to start the wizard:

Select System (RfcDestination) and click the left-to-right arrow to move the input parameter to the Selected list. Then click Next:

There are no options here so click Next:

Apps may only have one output parameter and it must always be a string, ideally a URL to some kind of report. Since our workflow has just one output, it’s selected automatically. Click Next:

Now for the first of the two most difficult aspects of publishing an app: giving it a name:

Once you’ve given it a name and description, click Next for the second most difficult publishing-an-app question:

Choosing an icon. If you are feeling adventurous, you can upload a custom icon. Once you’ve selected an icon, click Next:

If you are using projects – a LiveCompare security feature – you’ll be prompted to select the projects that should have access to the app. The current project is always selected and disabled (see SUG in the screenshot). Once you’ve selected the projects, click Next:

At this point you should review the registration details and go back and correct anything before clicking Finish.

The HTML Studio LiveCompare user interface has its own App Store. Use it to check that the app was successfully published:

To explore the app from a consumer user’s perspective, open the apps UI by clicking on the mobile phone icon in the toolbar:

Open the App Store, find the Premier League of Users app and add install it. Return to your home screen:

Open the app:

All LiveCompare apps have the same layout. The screen is split in half with variants (app configurations) on the left and results on the right. Open the Default Variant:

When we published the app we chose the System parameter as an input so it is available in the app’s UI. Click Run:

Wait a few seconds then click Refresh:

The app ran successfully. Open the Default Variant result:

You should see the dashboard with a link to the detail reports.

Congratulations! You have published your first LiveCompare app.

Improving the App

After a while you notice a common theme in the comments on the app store:

You decide to improve the app by letting the user choosing ‘N’ for the top N users.

Best Practice #2: Always Use a New Workspace When Improving An App

If you have several copies of the app workflow lying around it can be difficult to work out which one goes with the app. It’s simpler and safer to create a new workspace every time you want to edit an app.

In the Studio UI, select the app store then open the app:

Select the Copy to Workspace button:

Choose the new workspace and click Copy:

See that all the app’s workflows are copied to the workspace.

Open the Analysis workflow:

On the right-side you’ll find a parameter for inputting the number of categories for the results. We just need to surface this in the App Driver workflow and then in the app definition so that a user can set the value.

Open the App Driver workflow and select the Run Workflow action. Start the Bind Workflow wizard:

Choose the Analysis workspace workflow and click Next:

Select the input parameters as shown then click Next and click Finish. Add a parameter for the additional property:

Notice that the parameter is of type string. It would be better if this was an integer. It’s a string as a matter of convenience in the Analysis workflow because we were using the value in an ExecuteSQL action. Anyway to convert a value between types we use the Convert Data action:

  

Assign a default value – I used 5 – then run the workflow to make it works.

Now we are ready to publish a new version of the app.

Open the Studio App Store and select the app:

Select the Replace Workflow button:

Choose the v2 workspace and the App Driver workflow and click Next:

The new N (Integer) parameter is now available. Select it and move it to the Selected list and click Next:

Because N is an integer we have more control over the type of widget used in the app’s UI. Click Change:

A Slider makes most sense. Select Slider and configure the options as shown:

Click OK:

Click Next. We won’t change any other detail about the app so continue to click Next until you reach the Finish – Confirm Register App wizard page. Then click Finish.

Open the consumer apps UI (click on the mobile phone icon in the toolbar). Open the app. Click New Variant:

And complete the form. Click OK and open the new variant:

See how the N parameter has a slider widget. Move it around to see the value change. I set the value to 10 then ran the app:

Conclusion

Turning a workflow into an app is very easy. Remember to separate the workflow into the stuff that does the analysis and those parts that accept input and product a report. When improving an app, always start with a new workspace. Have fun and please don’t forget to share your comments below.