Calling other apps and transactions
Last updated
Was this helpful?
Last updated
Was this helpful?
Certain apps are designed so that they can be called by other apps. Creating the apps in such a ‘modular’ manner removes the need for duplicate development in PreBilt and supports a consistent experience for the users, whether they use an app directly from the menu or via another app that calls it.
For example, any apps that need to create or confirm transfer orders will jump into the WM Stock Movements app at the relevant point. The app doing the call will be referred to as the ‘parent’ app, and the app that is ‘called’ will be referred to as the ‘child’ app. Moving from one app to another can also be referred to as jumping from one app to another.
There are generally two different ways in which jumps to other apps are controlled:
Using a specific configuration option CALL_TRANSACTION (or similar) to identify the activity and ‘child’ app.
Identifying the ‘child’ app in a specific ACTION key.
If the configuration option CALL_TRANSACTION (or similar) is used, this needs to be set up in configuration as a String List. The String List should be created with an ‘Activity’ and ‘Transaction Code’ column.
The activities will need to be coded into the ‘parent’ app, which will then check this configuration option to see what ‘child’ transaction needs to be called at specific points in the program code.
Alternatively, if the ACTIONS are used to identify the ‘child’ app, this will again need to be coded into the ‘parent’ app.
For example, in Stock Enquiry, which allows multiple ‘jumps’ into General Postings, each allowed action is linked to the ‘child’ transaction when maintained in the app master data:
Often the ‘child’ app will require specific setup to support the seamless transition from the ‘parent’ app, and so therefore the ‘child’ app will be created with its own transaction code.
This allows the ‘child’ apps to be configured independently from the regular version of the app.
For example, the regular transaction code for the General Postings app may be PB2_GEN_POSTING, but an additional transaction for PB2_GEN_POSTING_512 will be created to allow the Stock Enquiry app (App number 512) to ‘jump’ to it.
Although having two versions of an app does increase the app master data maintenance, once it is undertaken initially, it does allow increased flexibility with regards to customising for each specific process flow. Some data fields will be passed from the parent app to the child app, removing data entry that would be required if the child app was processed by selecting it from a menu.
