Your Site's RSS Feed

Why React Hooks are Great

Sun, 10 Feb 2019 00:00:00 GMT

Here’s a pretty neat example of how React hooks allow for abstractions in really neat directions.

The example use case is for a loading spinner. A good loading UX won’t show a spinner for the first second or so, because the page might load near-instantly. In that case, you don’t want to show a quick flash of a loading spinner, since that would be jarring when you could just wait a big for the screen to show. If the app or data is taking longer than one second to load, then you want to show a loading spinner. And if the user has been waiting for more than five seconds, the component changes the text so the user doesn’t load interest.

The first file, the useTimeout hook, is very flexible. Notice that it’s used twice in the LoadingMessage component to easily give it different behavior depending on how long it’s been mounted.

// useTimeout.js
import { useEffect, useState } from 'react';

export default function useTimeout(ms) {
  const [isDone, setDone] = useState(false);

  useEffect(() => {
    const timerId = setTimeout(() => {
      setDone(true);
    }, ms);
    const cleanup = () => clearTimeout(timerId);
    return cleanup;
  }, []);

  return isDone;
}

// LoadingMessage.jsx
import React from 'react';
import useTimeout from './useTimeout';

export default function LoadingMessage() {
  // Don't show 'loading' before one second, to
  // avoid flicker of loading content
  const hasBeenWaiting = useTimeout(1000);

  // After 5 seconds, switch text to "Still loading..."
  const hasBeenWaitingLong = useTimeout(5000);
  const text = (hasBeenWaitingLong) ? "Still loading..." : "Loading...";

  if (!hasBeenWaiting) return null;
  return <p>{text}</p>;
}

Here’s a working example on CodePen.

Simple and Recursive Javascript Promises

Tue, 28 Mar 2017 00:00:00 GMT

When I learned functional programming, one of the most exciting moments was the realization that recursive functions can replace all for- and while-loops. Being able to use recursion effectively means that you can generalize for and while into something simpler and more powerful. Not that you always should, but this post is an example of exactly why such a thing is both powerful and practical.

To start with, here’s a recursive factorial function, the “Hello World” of recursion.

function factorial(n) {
    if (n < 2) return 1;
    return n * factorial(n - 1);
}

It’s not too difficult to understand or write, because multiplication is instantaneous, but what if the multiplication function returned a promise, like this?

function multiplyAsync(a, b) {
    return Promise.resolve(a * b);
}

How would you write a factorial function if you had to use the above multiplyAsync? Since the multiply function returns a promise, the factorial function will have to return a Promise too. Here’s one way to do it:

function factorialAsync(n) {
    if (n < 2) return Promise.resolve(1);
    return factorialAsync(n - 1)
    .then(n1 => multiplyAsync(n1, n));
}

This technique works for factorials, but not when order of operations matter, since it works “right-to-left”. What if we were trying to apply a list of changes to a database? Given:

[
    { user: 'Jeff', food: 'Ice Cream' },
    { user: 'Sonic', food: 'Chili Dogs' },
    { user: 'Donatello', food: 'Pizza' },
    { user: 'Jeff', food: 'Cheesecake' }
]

You would expect the fourth entry to overwrite the first. If we use the technique above, the code would expand to:

db.insert('Jeff', 'Cheesecake')
    .then('Donatello', 'Pizza')
    .then('Sonic', 'Chili Dogs')
    .then('Jeff', 'Ice Cream');

Backwards.

For example, what if we were trying to insert over 9000 things into a database in groups of 500? The above method would insert the last 500 things first, then the previous 500, and so on. Not very desirable behavior.

So, if your database library gives you a function like

db.insertRecords(records); // returns a promise

How would you write the following function?

function insertToDatabaseInBatches(recordsToInsert, batchSize) {
    // A little help?
}

Here’s the best I could come up with:

function insertToDatabaseInBatches(recordsToInsert, batchSize) {
    if (recordsToInsert.length === 0) return Promise.resolve();

    const batch = recordsToInsert.slice(0, batchSize);
    const remaining = recordsToInsert.slice(batchSize);

    return db.insertRecords(batch)
    .then(() => insertToDatabaseInBatches(remaining, batchSize));
}

Inserting a bunch of records into a database, in batches, asynchronously, in 7 lines of code. Not bad, recursion.

Show SCN: The Better Logger I Promised

Tue, 30 Sep 2014 00:00:00 GMT

Originally posted at https://blogs.sap.com/2014/09/30/show-scn-the-better-logger-i-promised/.

A month back, I wrote a short blog about the application log, and how great it would be to have yet another object oriented wrapper around the SBAL function group and friends. Well, I wasn’t kidding. I just put up a working version on Github, and added some documentation to explain some of the features I thought would make a logger tool great. It’s been done fifty times before, but I haven’t seen any of them with the features I describe. It’s all working, so feel free to kick the tires, fork the project, and please, please, let me know what you think!

epeterson320/ABAP-Logger · GitHub

Here is my original post: What Would a Developer-Friendly Application Log Look Like?

Below is most of the readme from Github:

ZCL_LOGGER

SAP Logging as painless as any other language

One of these things is not like the others One of the most effective ways of debugging and inspecting a program’s operations is by writing to a log. Logging is so powerful, just about every language has some way of doing it. For example, if you want to write to a log in javascript, you just need to write the following line of code:

console.log(“Leapin’ lizards, something went wrong!”);

Or how about in Ruby? Ruby has the added benefit of different levels of messages.

require ‘logger’
log = Logger.new(‘logfile.log’)
log.warn(“You’re on thin ice, bud.”)
log.info(“Things are normal again.”)

Writing an Android app? You’re in luck – you can log and optionally tag messages, all in one line of Java.

Log.e(‘MAPS_INTERFACE’, ‘The system is down!!!’);

So, how does ABAP logging stack up to the other languages? What code is required to log a string to be viewed later?

DATA: header TYPE bal_s_log,
        handle TYPE balloghndl,
        handles_to_save TYPE bal_t_logh.

header-object = ‘ZINTERFACES’.
header-subobject = ‘ACCOUNTING’.
header-extnumber = ‘Stuff imported from legacy systems’.

CALL FUNCTION ‘BAL_LOG_CREATE’
    EXPORTING
    i_s_log      = header
    IMPORTING
    e_log_handle = handle.

CALL FUNCTION ‘BAL_LOG_MSG_ADD_FREE_TEXT’
    EXPORTING
    i_log_handle = handle
    i_msgty = ‘E’
    i_text = ‘You see, what had happened was…’.
CALL FUNCTION ‘BAL_DB_SAVE’
    EXPORTING
    i_t_log_handle = handles_to_save.

If you’re not asleep after writing all that, then you’ve at least forgot what you were programming before you had to write to a log. If anything, logging should be QUICK so you can get on with the real programming!

Get out of my way

A better log would barely interrupt my code, so I can output messages in one line, and you don’t lose the big picture as you are reading it. What do you wish the ABAP example above looked like? How about this:

DATA: log TYPE REF TO zcl_logger.
log = zcl_logger=>new( object = ‘ZINTERFACES’
                        subobject = ‘ACCOUNTING’
                        desc = ‘Stuff imported from legacy systems’ ).

log->e( ‘You see, what had happened was…’ ).

All the information, none of the boilerplate. This is the goal of ZCL_LOGGER.

Log anything

Making use of SAP’s run-time type services, we can pass almost anything we might want to log to an instance of ZCL_LOGGER, and it will do the heavy lifting.

Log a string!

log->s( ‘Document 4800095710 created successfully’ ).

Log a bapi return message!

DATA: rtn TYPE bapiret2.
log->add( rtn ).

Log a…gasp…TABLE of bapi return messages!

DATA: msgs TYPE TABLE OF bapiret2.
log->add( msgs ).

Log an exception? Yep!

TRY.
    rubber_band_powered_spaceship=>fly_to( the_moon ).
    CATCH zcx_not_enough_power INTO err.
    log->e( err ).
ENDTRY.

Log the current system message.

MESSAGE e001(oo) WITH foo bar baz INTO dummy.
log->add( ). “you don’t even need to pass anything in, bro.

Log the return of a BDC call.

CALL TRANSACTION ‘CO07’ USING bdc_tab MESSAGES INTO bdc_messages.
log->add( bdc_messages ).

And that’s every scenario I’ve been able to think of, so far.

Don’t Ignore SAP’s Strengths

As frustrating as it can sometimes be, the SAP environment has a lot of power, and it would be good not to ignore it. Transaction code SLG1 views and filters logs with ease, and it allows for added context variables and parameters. A new logger class should not reinvent the wheel, the wheelbarrow, or the mechanisms for saving and displaying logs.

If you have an instance of a log object, you can add context variables and a problem class, two of a few things that SLG1 handles well.

log->w( obj_to_log = ‘Document created with errors’ “<– Which document? Needs context.
        context = new_document ). “<– Here’s the context

Since this log is designed to be simple, it has compromised a lot of the more exotic function modules in the SBAL family. If your log needs to use one of these function modules, the log header, handle and database id are all read-only members of the class, so you can pass them right along to the function module.

log->i( ‘Results of system analysis’ ).
CALL FUNCTION ‘BAL_LOG_MSG_CUMULATE’
    EXPORTING
    i_log_handle = log->handle
    i_s_msg = l_msg
    i_compare_attributes = abap_true.

Chainable

It’s 2014, so yes, you can chain method calls.

zcl_logger=>new( object = ‘foo’ )->e( ‘Bad things happened: See details’ )->e( error ).

What Would a Developer-Friendly Application Log Look Like?

Wed, 30 Jul 2014 00:00:00 GMT

Originally posted at https://blogs.sap.com/2014/07/30/what-would-a-developer-friendly-application-log-look-like/.

9/30/14 UPDATE: I’ve begun work on a tool like I describe here. It’s detailed in this post: Show SCN: The better logger I promised

Do you ever have this problem? You’re in the middle of writing a fantastic ABAP program. It hums, it purrs, it looks reeeeally good. The code is so clean uncle Bob would be proud. You use the best design patterns and your application is modularized well. Then you realize you need to log a few lines of text to view later in SLG1. Your heart sinks. Your robust, clean application is about to become polluted by countless 10-line calls to FM ‘BALLOGCREATE’ and its fellow hoodlums, all because you wanted to save the output of a BAPI you called. First world problems, AMIRITE? Anyone?

The obvious solution is to put an object-oriented wrapper around these functions. This solution is so obvious, in fact, that every department in SAP has written their own verison of it, and my company has added two more. This is consistent with SAP’s approach to developer tools: Quantity Guaranteed.

So why do we need another OO wrapper? Well, because I believe in the power of collaboration, for one. None of the other logs have been designed by the developer community. Another reason is that logs have come a long way since 1999, when SAP released their function modules for the application log, and developers are used to a more concise syntax. For instance, if I want to write to the console in javascript, it’s:

console.log(‘The System is Down’);

but in SAP, I have to declare 2 variables, then spend a page of code calling function modules BALLOGCREATE, BALLOGMSGADD, and BALDB_SAVE. Part of the reason is that SAP has multiple logs, while a web browser only logs messages in one console. So when you log anything in SAP, it must go to a specific application log object and sub-object. Android (java) also writes to multiple logs. Its logs are called with two arguments, tag and message, like:

Log.e(“SystemMsgs”, “The system is Down”);

If logging in ABAP was going to be just as awesome (and I know it can be), what would it look like? Please post your ideas and discuss! Once enough good ideas are gathered, I’d like to start building something on github. Anyone is welcome to contribute code or just ideas and insights. Here’s an example what I think would make a good application log API:

log = zcl_app_log=>get( object = ‘ZFICO’ subobject = ‘INTERFACES’ ).

TRY.
    zcl_accounting=>do_some_important_upload( ).
    log->add( ‘The interface has finished’ ).
  CATCH zcx_upload_failed INTO err.
    log->add( err ).
ENDTRY.

Best Practices for Users to Maintain a Z-Table

Tue, 01 Oct 2013 00:00:00 GMT

Originally posted at https://blogs.sap.com/2013/10/01/best-practices-for-users-to-maintain-a-z-table/

UI design is one of the most exciting parts about my job as a developer. It is art, programming, and psychology at the same time. A few weeks ago I had the requirement to create a table maintenance program for our business users to maintain a large custom database table. A few administrators were then going to add, modify and delete entries in this custom table that would in turn be used by other background programs. Sounds simple, I thought. It wasn’t. I learned a lot about creating a table maintenance dialog, not the least of which was how to spell “maintenance” correctly. I wanted to summarize a few things I learned from this adventure.

Bad Doctors, T.V. Writers and User Interfaces The television show The Walking Dead is getting ready to premiere its fourth season and has the highest viewership among any cable TV show in the U.S. It also received much criticism for being very slow-moving and having “filler episodes” some weeks with little to no action. “Our heroes should be fighting off more zombies and rescuing other survivors in the post-apocalyptic world,” said the fans. But the writers knew better. An hour of baseball bats and machine guns and blood n’ guts every week would get old quickly. So the writers added complex father-son relationships, outcasts trying to find their place, and familiar love triangles set amidst an extreme environment. As a result, people kept watching.

Likewise, If I went to the doctor and he or she said “I’m not sure what to prescribe, let me know what medicine you want and I’ll give that to you,” I’d run out of the clinic as fast as possible. Actually I might steal all the tongue depressors on the way out, because I’m never returning to that doctor, and tongue depressors intrigue me.

What’s the point of these examples? I’m trying to show that the consumer often doesn’t know what they want. I’m not going to crowdsource medical advice, and neither will I give the user the interface they tell me they want. I’m going to tell him or her what’s best, because I’m a designer/developer and they don’t know the appropriate time to use a radiobutton vs. a checkbox, let alone design the screen layout and flow for a program they need.

Certainly you, the developer, need to listen closely to the user’s needs (and to any functional analyst) but the technical details of the final application, including UI “feel,” ought to be your responsibility. Users and functional types may strongly disagree with your UI choices, so it is important to communicate as clearly and effectively as possible. You must convince them why their UI is the wrong choice. In this age of agile development, it’s not a good excuse to say “But I gave you exactly what the design spec asked for!” when the user whines about your program.

If you give the user exactly what they want, they’ll likely be back every month wanting some little change in the program. If you seek to understand their need and argue well for a better (read: more standard) UI, they will be very pleased with the final result, and the program will require less maintenance over its lifecycle.

Users and Z-Tables Now that I’ve got that rant out of the way, one of the toughest UI challenges for me was creating a table maintenance dialog. TMD’s, as I’ll call them, are programs with a very simple task that are very complicated “under the hood.” I’ve compiled nine tips and tricks about how to create one well.

This is 5% Table and 95% User Any database table can be maintained by only the four CRUD operations (create, read, update, and delete). So, how difficult can it be to put a front end on four different database operations? Not difficult, if you’re okay with annoying everyone in your company, filling the database with bad data, and all-around mediocrity in your life.

If you want to implement a good table maintenance dialog, however, you need to worry about security, data validation, message handling, view restrictions, and more. Users (at least the human ones) will do everything they can to screw up and misuse a program. Some may be downright evil. As said in a 2008 commentary about Craigslist spammers, “When you fail to design for evil, you have failed your community.”

Most TMD design requirements will fall into one of two categories:

Getting the correct slice of data FROM the database to the user’s display. Making sure only good user input goes INTO the database.

Use SAP’s Table Maintenance Generator The good news is, the bulk of a good table maintenance dialog will be built by SAP. This may seem painfully obvious to some, but when I got the requirement to build a table maintenance dialog I was told, “We’ve done this for another Z-table before; here is a program for you to copy.” The program was a module pool with 1300 lines of code, 7 dynpro screens, and five GUI statuses. All to create, read, change, and delete entries from one database table! I would not let that program near children.

If you didn’t know, SAP transaction SM30 allows end-users to maintain database tables directly. It’s far prettier than any dialog you have time to create, and you can use the ABAP dictionary to integrate your custom table into this transaction.

Isn’t it (comparatively) pretty?

Table maintenance dialogs are deceptively complex. To keep the amount of code you need to write under control, stay as close to SAP standard as possible. To save you and your coworkers many headaches, generate a table maintenance dialog the standard way. If you don’t know how, here’s the documentation.

SAP Library – Create a Table Maintenance Dialog.

Now you’ve got a program that allows users to maintain a table. And you wrote zero lines of code! You must be an amazing programmer. You can maintain the table via SM30 (Call View Maintenance) now.

Use a Custom Transaction Instead of SM30 At my company, end users do not have access to transaction SM30. That was the justification given to me when I asked about another custom table maintenance dialog for a different Z-Table (In all fairness, this reinvented wheel was only 300 lines of code and three dynpros). Instead of using transaction SM30 to maintain a table, there are two better ways to use the table maintenance dialog, and you won’t have to create any dynpro screens. Have I mentioned I hate dynpros?

Parameter Transaction: Requires no ABAP. From SE93, create a new transaction. When prompted for the type, choose “parameter transaction.” Set SM30 as the default transaction and check “skip initial screen.” This works great for tables that won’t have many entries – my rule of thumb is fifty or less.

Add the following default values:

Field	Value
UPDATE	X
VIEWNAME	(name of your Z-Table)

ABAP Report: Easier to customize. Build a custom report and call function module “VIEWMAINTENANCECALL”. This requires maintenance of a custom report, but it has all the flexibility of an ABAP program. This is a big advantage if you want to add a selection screen or build the TMD into another application.

Widen the Overview Window for Tables With 5-10 Fields. Making your users scroll horizontally is as annoying as websites that automatically play music or game invitations from distant friends on Facebook. If you have more than 4 fields in the table, this is essential!

Rule of thumb: Be less annoying than this.

To change the standard screen:

From SE11 (ABAP Dictionary), open the screen to modify your Z-Table. On the menu, choose Utilities ->Table Maintenance Generator.

From the menu, choose Environment -> Modification -> Maintenance Screens and select the screen you want to change.

To widen the overview window, click “Layout” and simply drag the side of the table control to widen it. If there are a great many fields, you may not be able to fit all of them on the screen. Your users would have to scroll horizontally, and now would be appropriate for you to shed a tear. Save and activate the screen.

I’ve recently seen another way of doing this via an enhancement which is slightly more complicated, but far more adaptive and robust. It’s described in the blog SM30, change standard width of Tablecontrol.

Use a Two-Step Dialog for Tables with 10+ fields.

If the table has more than 10 fields, you’ll be unable to avoid making your users scroll horizontally. One way to make this easier is to use a two-step dialog. When the users add a new entry, they will be taken to a separate screen where they can edit all the fields for one record.

Disable Input for Read-only Fields WITHOUT Creating a Database View.

One way to disable input is to mark the fields as “Read-Only” in the ABAP dictionary, but this is only possible for database views, not transparent tables. If you are working with a transparent table and not a maintenance view, customizing this screen is easier than creating and maintaining a separate database view. Open the screen for modification as in step 4. Click the “Element List” tab and un-check the boxes in the Input column for those fields you do not want users to control (in case you will be filling them in automatically with custom code). Examples of this are “Created By” and “Created On.”

Use Custom Logic When Appropriate. A good database table needs validated, clean data. If you cannot ensure this via check tables in the table definition, there are many points in the SAP standard dialog where you can add custom code to validate entries or do whatever else you need. Enhancing a table maintenance dialog can get complicated, however, so the ins and outs will not be discussed here.

Some great resources for those who are interested:

Table Maintenance Generator and its Modifications

SAP Library – Extended Table Maintenance Events.

Add a Custom Selection Screen for 50+ Records If the custom table is large, its administrators may not want to see every entry on the overview screen. They want to see if specific entries exist before adding new ones. This was a requirement by my business, and based on an SCN search for “filter sm30 selection screen,” I saw others had the same need.

It’s quite easy to restrict the display via SM30, but this is only after everything has been loaded. The built-in selection criteria also gives only a small dialog box (not to mention you’re directly using SM30).

This is no selection screen for end users!

Instead, it’s better to create a custom report with select-options that calls the function module “VIEWMAINTENANCECALL” I mentioned above. The FM requires all the select-options to be in one parameter. Here are the highlights of the code needed for that.

Add a Selection Screen to a Table Maintenance Dialog

Integrate Your TMD Into a View Cluster or Config Table Once the INNER workings of a table maintenance dialog are optimized for user pleasure, give it context in the OUTSIDE environment. Add it to a view cluster so multiple related tables can be maintained at once, or add it to the IMG config settings if appropriate.

These activities are detailed in two entries from my favorite series on SCN (so far):

Getting the basics right – Creating the perfect config table (Part 2, View Clusters)

Getting the basics right – Creating the perfect config table (Part 4, IMG integration)

Good UI Goes a Long Way

If this is done well, users will be happy, or at least not angry, and that’s what we developers all hope for. Less time will be spent responding to users’ little requests in the future, and you will be far better off for it.

So, what other ways have you been able to improve upon the standard TMD?

A Dream for SE80: Github Integration

Wed, 18 Sep 2013 00:00:00 GMT

Originally posted at https://blogs.sap.com/2013/09/18/a-dream-for-se80-github-integration/

When I heard Code Exchange was closing, I was bummed. I read that a new code exchange 2.0 is being developed, but as I write this it is still under construction. As many people have pointed out, however, that doesn’t need to stop SAP developers from sharing code with one another.

For us ABAPers, we have few choices on how to share code, and it’s not easy to share non-code development objects. For simple programs, I can copy and paste from any forum, but what about a program has a dozen custom data elements and a few custom global classes? Well, thanks to the fantastic SAPLink project (with which I am not affiliated), that has become a lot easier. It’s as easy as downloading a .nugg file and importing it, or so I hear.

I want to take the idea behind SAPLink one step further. Instead of searching the web via browser (and by the web, I mean Google Code and Github) for a .nugg file, downloading it to a file directory, and importing it via SAPGUI, can’t we do this all from SAPGUI? We’re trying to share code, so why not share while using the place where we work on the code, i.e. SE80? If you’re thinking, “That’s not where I work on the code! I use Eclipse!” well, good for you. I hope to join your smug ranks soon, but most of what I’m proposing is probably applicable to Eclipse development too. Certainly an ABAP-based github client is reusable.

So rather than spending 5 minutes explaining it, I spent half an hour stumbling through MS Paint, drawing what I had in mind.

Seriously, how cool would this be?

From what I can tell, although it’s not possible to add tools to SE80 like this, it would still be very helpful to copy the general UI into another transaction. It could have two or three pushbuttons on the left like SE80, but they would be along the lines of Github Repositories, Search Github, and Package Browser. From github repositories, you could view your own repos. Search Github would return a results list of repos, from which you could view the contents, readme, and import as an SAP development package. Package Browser would allow a user to select and push his or her development packages to github.

Right now I’m thinking a 1-to-1 ratio of packages to repositories would work best for code management and sharing. If I download/clone a repository, it becomes a package, and if I push a package to github, it becomes a repository, and any subpackages do not – they are just part of the .nugg file.

There are a few problems that need answers if this will get developed, such as how to handle the github readme files, but boy howdy, this would be a dream come true.

If this were developed, would you use it? What other features would you like to see?

Add a Selection Screen to a Table Maintenance Dialog

Thu, 22 Aug 2013 00:00:00 GMT

Originally posted at https://blogs.sap.com/2013/08/22/add-a-selection-screen-to-a-table-maintenance-dialog/.

When end users will maintain a z-table with 100+ rows, it helps to be able to restrict the selection by any number of selection criteria. This document attempts to define a “best practice” method for calling a table maintenance dialog from a selection screen.

Current Table Maintenance

The standard way to show a table maintenance dialog is via SM30, Call View Maintenance –

– or a custom parameter transaction that calls SM30 for a specific table, with parameters VIEWNAME and UPDATE = ‘X’.

Neither of these provide an initial selection screen. Entries can be restricted by checking the “Enter conditions” radiobutton, but users are more familiar with selection screens than with the dialog box that pops up. Therefore it is good UI to use a selection screen instead of the “Enter conditions” radiobutton.

Example Selection Screen Definition

In this example, an executable report has been created with selection screen.

REPORT  z_maintain_mytable.

DATA mytable    TYPE z_mytable.
DATA selections TYPE TABLE OF vimsellist.
DATA selection  TYPE vimsellist.

SELECT-OPTIONS: so_selop1 FOR mytable–myfield1,
                 so_selop2 FOR mytable–myfield2.

PARAMETERS: p_param1 TYPE z_mytable–myfield3,
            p_param2 TYPE z_mytable–myfield4.

Calling Function Modules

When the user clicks execute, the program needs to read their selections and call the table maintenance dialog. The following code shows how this is easily done by using function modules ‘VIEWRANGETABTOSELLIST’ and ‘VIEWMAINTENANCE_CALL’.

START-OF-SELECTION.

  DEFINE addsel.
    CALL FUNCTION ‘VIEW_RANGETAB_TO_SELLIST’
      EXPORTING
        fieldname          = &1
        append_conjunction = ‘AND’
      TABLES
        sellist            = selections
        rangetab           = &2[].
  END-OF-DEFINITION.

  DEFINE addparam.
    IF &2 IS NOT INITIAL.
      CLEAR selection.
      selection–viewfield = &1.
      selection–value = &2.
      selection–and_or = ‘AND’.
      selection–operator = ‘EQ’.
      APPEND selection TO selections.
    ENDIF.
  END-OF-DEFINITION.

  add_sel ‘MYFIELD1’ so_selop1.
  add_sel ‘MYFIELD2’ so_selop2.
  add_par ‘MYFIELD3′ p_param1.
  add_par ‘MYFIELD4′ p_param2.

  CALL FUNCTION ‘VIEW_MAINTENANCE_CALL’
    EXPORTING
      action                = ‘U’ “for Update
      view_name             = ‘Z_MYTABLE’
      complex_selconds_used = ‘X’
    TABLES
      dba_sellist           = selections
    EXCEPTIONS
      OTHERS                = 1.

  IF sy–subrc = 1.
    MESSAGE ID sy–msgid TYPE sy–msgty NUMBER sy–msgno
               WITH sy–msgv1 sy–msgv2 sy–msgv3 sy–msgv4.
  ENDIF.

Horray! That is all. In only 46 lines (plus two for every select-option or parameter), this will bring the user to from the selection-screen to the table maintenance screen.

This is a collaborative document. If there are better ways of achieving this functionality don’t hesitate to chime in and contribute!