Let’s Crowd Source a POWL Based Universal Worklist Design for ERP

The idea

Now while there’s a version 1.0 HTML5 All in One SAP Inbox due any day now (or so I’m told), some of us need to do something now about having a single place for a user to go to see there various workflows from multiple back-end systems. In the Portal, this was the UWL. In my mind, the Portal UWL was a good idea, but plagued with the fact that there was a chasm between the workflow people and the Portal people, and lots of strange configuration where it was hard to connect all the dots.

Now as of EHP5+, there was a semi-replacement available within ERP. You can find more about this in a great informative blog from Sagar Gadre  that can be found here.

While it looks like all the pieces are here, I wanted to extend this design somewhat, and make the solution in some ways, more generic, but not so in other ways.

The Warning

I put together this blog as I needed to demonstrate a solution for my customer’s SI partner to help them see how the solution can hang together from a pure prototype perspective, and because I have a forward thinking manager at my current customer who understands the power of community, they agreed that it would be a good idea to take my workings and put it on SCN to make sure people don’t scream at us saying “You’re butchering the intent of our solution” (which the combination of POWL_TYPE’s we use could be doing exactly that), or preferably offering the following advice: “Here’s a better idea rather than doing X”. e.g. My testing of this solution is very superficial.

Hence, below is a solution so far that does not contain custom development and can be configured (to a degree) completely out of the box. I’ve looked a little below the covers to see how caching of work items occurs for each query, but I realise that if a connected system is down, then I’m not sure how well that is handled if the user presses refresh right now (guessing it’s not). In my mind, considering the importance of the UWL, you could either train the users about this with outage notifications (if you happen to need one), or you could build a process to remove the system temporarily from refreshes during an outage.

You’ll also need to run this in a Portal or NWBC (I’m using NWBC), and understand how to use the API calls that the underlying framework uses (we’re using OBN for all navigation as I think it’s better as it potentially places the user in the right area of the solution when they process a task).

Substitution is limited to HR workflows built for substitution (as there’s security code involved), though could likely be extended for other workflows if you look into it further.

In other words, this is a start point for discussion, not a final design (though appears to be mostly working). So please provide direction so others reading can benefit!

The Requirements

So what do we want – well a picture is worth a thousand words so here you go:

In short, there are 3 categories – All tasks (with a filter for high priority tasks), People Related Tasks (e.g. Timesheets, Leave Requests, probably others should be listed too, but wasn’t in my scenario just yet – separated out because it’s usually something that needs focus), Incident Related Tasks (High Priority Tasks and Normal Priority Tasks since safety incidents should be focused on!).

The point of using this view is to see within a small area, what work do I have to help the users manage their tasks. Obviously this layout suits where I am, but the steps should be similar if you go the same way.

FYI – I also see this being the same source of data that could be used for the lanes page introduced by Renewal where you see dashboards of Workflow information, hence thinking also about the future and limiting the background tasks to support Worklists.

Other requirements include:

• Multiple back-end systems (refer to Sagar’s blog about setting this up) – though at some point, need to consider what to do if planned down time of a connected system occurs.
• Refresh of the UWL so the user doesn’t get a time-out if they leave the tab open in NWBC
• Substitution (though haven’t explored this yet and would refer you again to Sagar’s various contributions)
• Fast

How to configure the initial guts of it all

The high level steps are:

1. Create application
2. Create categories
3. Link relevant POWL types (feeder classes) to our application
4. Create our POWL queries
5. Link the queries to our application
6. Create PFCG Role
7. Configure new Application Configuration
8. Set up batch job to refresh worklists
9. Set up refresh rate of POWL when running
10. Next steps not documented include defining all tasks, OBN’s, parameters, etc.

So let’s start with Step 1…

Note – I’m expecting you can figure out the steps involved between the statements/screenshots…Happy to field questions if required though.

Create Application

Start Transaction FPB_MAINTAIN_HIER and create your own application:

As you can see, I don’t think the UWL name or Inbox naming is very nice, and coming from a process navigation user experience here, I’ve gone with Centralised Task Processing. Still a bit crappy, so if you have come up with a great name for end users; would love to hear your application name.

Create Categories

Start transaction POWL_CAT and create your categories.

New Entries as follows:

Link relevant POWL types (feeder classes) to our application

Run transaction POWL_TYPER and assign POWL types being used to our application.

For reference, we’re using IBO_INBOX_WI as the main feeder for most of the scenarios, except for timesheets where we use the dedicated feeder (MSS_POWL_CATS_APPROVAL_1) from the latest MSS inbox example, since timesheets are a single workflow item now days, but it’s nice to see the number of timesheets entered for the week so you easily know when everyone has submitted. Note – I’m assuming by using mainly IBO_INBOX_WI, that the singleton usage within this application will protect us from unnecessarily retrieving worklists from all systems multiple times, but that’s purely hypothetical as I’ve only scratched the surface of looking into these feeders.

Create Queries

We need to create:

• All Tasks based on IBO_INBOX_WI (no filter)
• High Priority Tasks based on IBO_INBOX_WI (Filter high priority)
• People Related Tasks
  • Timesheet Tasks based on MSS_POWL_CATS_APPROVAL_1
  • Leave Requests based on IBO_INBOX_WI (filter by task id)
• Incident Related Tasks
  • High Priority Tasks based on IBO_INBOX_WI (but needs enhancement) (Filter by task ids!)
  • Normal Priority Tasks based on IBO_INBOX_WI (but needs enhancement) (Filter by task ids!)

To do this, start transaction powl_query then create relevant queries, grouped by Categories using underlying POWL Type (Feeder). Set parameters to differentiate each Query.

No parameters required for All tasks

After selecting the query id (and I recommend saving before doing the next step due to an SAP bug I experience every now and then) – Press Query Parameters to only select High Priority items.

etc.; except for Timesheets which looks like as follows:

Notes:

• Leave sync off as it’s a nicer experience IMO.
• The query parameters support filtering on a single task, but really I need an option to select multiple tasks in the future. Guessing I’ll need to use the existing feeder class as a super class to add this option…
  

Link the queries to our application

Start Transaction POWL_QUERYR and assign your queries.

Create PFCG Role

Now if security gives you access, we create a test role to try this out (you would also use this role to test out the OBN connectivity potentially).

Run transaction PFCG.  Create new Single Role, add Folder, then add Web Dynpro Application:

Use IBO_WDA_INBOX Web Dynpro Application as your application (though note – This locks the name of the application to Lean Workflow Inbox which sucks, so for the real version, you probably need to create your own Web Dynpro application to configure against. Not sure why SAP haven’t addressed this as config yet.)

Configure new Application Configuration

Name the new Application Configuration and press Application Configuration to launch the browser.

Copy HRMSS_AC_POWL_INBOX_2 application configuration to your new Application Configuration name (since it looks a little more appropriate than the default IBO application configuration)

Once created, you need to copy the both design configuration items to your own configuration. Do this by clicking on the links, cancelling going into change mode, then copying the HRMSS config to your own config. For each config, you need to change the POWL Application id over to your own Application Id.

Once created, the Assign configuration button hidden away in the table area of the application configuration can be used to change it to your configuration.

Back in pfcg land, save your PFCG role, and test within NWBC using the URL: sap-nwbc://http://<ERP FQDN>:8000/nwbc/~roletest/YDEMO_UWL

Hey presto:

Set up batch job to refresh queries

Now this needs a lot more thinking through and knowing how the feeders actually work, but schedule carefully how the POWL_WLOAD batch program should run to populate users’ inboxes. I’d go with 30 minutes, and just use my whole Application as the batch job in this case. Also, small test system, so 1 query per job, and max 1 parallel jobs. Default values in this batch job can bring down your dev system! (FYI – This is obvious, not learnt from my own mistake)

Set up refresh rate of POWL when running

A useful feature (if I understand it correctly), is to set the timer on the Inbox to refresh regularly, which theoretically, should mean the Web Dynpro application doesn’t time-out. I’ve tested this and noted it does refresh, but not sure if it completely stops time-outs.

Will this work? Is there a better way?

Now time to hand it over to anyone out there involved in something similar, or experienced with why it’s the “Lean” inbox rather than the new UWL…My job to set direction for the project I’m on is done (not really, but technically I shouldn’t have done this either), but I know this is all new to everyone on implementations, and it does suck when you get a direction from an architect (or SAP) which is impossible to make work.

As stated, I still have not addressed:

• Connected system failures that may arise;
• Optimising performance for larger user bases;
• Different queries for different user groups (e.g. Non-Managers typically don’t approve timesheets)
• Running real workflows through this beyond minimal unit testing.
• Substitution functionality (since substituting all workflows is unlikely to work without changing non-HR workflows from a security perspective).

Thanks for reading and hope we can make this better and usable until 2.0 of the new truly universal inbox comes out from SAP!