Creating AppWorx Chains from Banner Processes and Reports

Presented by:Loretta Sampson, Systems Analyst

Missouri State UniversitySpringfield, Missouri

Use Banner and In-House Objects within AppWorx

• Get Delivered Banner Reports into AppWorx Quickly

• Launch in-house code and processes via AppWorx

– Presumes familiarity with BANNER Objects

– Presumes familiarity with the product “AppWorx”

2

• BANNER and AppWorx are “business partners”– This is why the “MKBANNER” process works as it does

• This session utilizes MSU “shop standards”– “Shop Standards” are encouraged at any institution

• CHAIN is analogous to a JOB

• MODULE is analogous to a STEP within a JOB

• Snapshot of the AppWorx window

• The CHECK-MARK is the REQUEST screen

1. Navigate to the REQUESTS screen. Choose the module named “MKBANNER” – i.e. Make a Banner Report. Press “REQUEST…”

2. The SUBMIT form displays. You might tag the job with your initials for easier identification if there are several queues.

Double-click within the highlighted line to provide your selection(s).

(a SUBMIT button is on this screen, just not clipped out here)

3. Choose the report(s) you are after. FGRCASH is selected and moved. FGRTBEX is highlighted, but not yet moved via the > button.

Click “OK”. The prior screen re-displays; click the “SUBMIT” button. MKBANNER will execute and finish.

4. At this point, an AppWorx module exists with that same name, description, and default parameters of the BANNER module which was selected.

Recap: Executing MKBANNER with the FGRCASH selection creates a mirror image of the BANNER / FGRCASH object called a module.

AppWorx modules may be executed (as the MKBANNER module was executed), but MSU has a standard of only executing chains. This has the advantage of better “grouping” and “security” management by utilizing naming conventions.

5. Banner modules download as being within the “BANNER” application. We always keep the defaults associated with the “APPLICATION” and the “EXECUTION QUEUE”. (For in-house modules, we utilize our own).

6. Now, we EDIT this module.

On the “General” tab:

1 Leave BANNER as the default “Application”2 Leave the “Program” block defaults3 Leave the BANNER queue within the “Execution Options” block4 Select the appropriate “Notification”

Here I choose GENERAL_ACCOUNTING

Other NOTIFICATION options will need to be created – see HELP for that

This can get “fancy”, but we’re doing the basics to get a report delivered.

7. Now the “Prompts” tab.– Take all defaults. This one only has SYSDATE. Some reports have many

prompts.– You may edit the date as shown. This will be done at the CHAIN level as well.

8. Here is an example of several PROMPTS that come along when downloaded. Just leave them all alone.

They may contain a value which can be overwritten; blank usually means “all”.

9. Now the ROLES tab. These are the three Roles that should be in our modules. Save your work. The module is ready – a module is a building block…. MODULES will not be executed at MSU.

10. To create a new CHAIN. Navigate to the screen and choose NEW.

While on the GENERAL tab….– Supply the appropriate prefix for the name – here it is FNS_FGRCASH– Select the appropriate Application – here it is FNS-RUN (continued below)

– Start the description with a word that describes the functionality. This technique will aid the Operators later on when they sort or search for a “type” of chain.

• Report – a chain containing one report• Reports – a chain containing more than one report• Interface – a chain that interfaces with something else• Process – a chain that performs Banner work/functions

– Within EXECUTION OPTIONS• If you know it is a REPORT ONLY with no updating, choose

IMMEDIATE• If you think it does any processing in or out of BANNER, choose

HOLD

– Everything else is defaulted

11. Navigate to COMPONENTS– Choose the CHAINS/MODULES button

– Slide down to the module you need. (Note the “M” in the “Type” column).

– Choose SUCCESSOR• It will hop over into your chain.

– This component is now a copy of the base module.. We always leave the base module alone. Any fooling around happens within the component (copy) in the chain.

Now it is time for a concept.

• Basically, we need to pass a parameter. – When CHAINS are newly created they have no prompts; it is the MODULE

within the CHAIN that has the prompts.

• BUT… when CHAINS are requested, only CHAIN- level prompts are available to the user; MODULE-level prompts are not accessible

• PROMPTS must be copied from the module level to the chain level.

• AND… the module level has to end up knowing about the value from the chain level.

• Notice how the variable #SYSDATE in the MODULE is replaced by today’s date when submitting the CHAIN

12. At the CHAIN-PROMPT tab choose COPY

13. Navigate to the module whose PROMPT(s) you want; Choose OK.

14.Here the SYSDATE is copied. If not done before, SYSDATE must be edited to the system variable #SYSDATE.

Read more about system variables in HELP or the manual. Note, here we have one (1) prompt.

When requested, the job will display and default with the System Date. It can be overwritten with a past or future date at that time.

15. At the CHAIN-COMPONENTS tab, highlight the component to work with in the chain.1.The chain-tabs remain at the top of the screen

2.The component(module)-tabs are along the right-hand side.a.Choose the PROMPTS tab within the right-hand side.

b.Assign the VALUE column in tandem with the CHAIN prompt1.The first value from the chain replaces the first value in the component2.The second value from the chain replaces the second value in the component3.And so on…they are typically in pairs.

16. At the CHAIN-ROLES tab, we will assign the ROLE(s) that have permissions to execute this report – in this case FINANCE.

The standard at MSU is that MISUSER-EDIT, OPERATOR-EDIT, and DBA should always be assigned.

Choose a role from the bottom and press the ^ button.

17. MSU chains will often have four ROLES like this.

18. We will add ABORT CHAIN notes, and CHAIN notes. You may use HTML or not; check the box accordingly.

19. By checking and unchecking the html box, you can review what you are keying. (Plain text can also be used; just don’t use HTML at all).

20. Repeat for the CHAIN notes. Describe important information about the CHAIN.

• Execute your chain and review the output. (Request it just like you did with MKBANNER)

• Congratulations! You now know how to create an APPWORX CHAIN!

• Let’s see some general information and follow an in-house CHAIN with in-house MODULES

• This is how you can easily find chains based on the application, prefix, or description.

• This is where we keep our “support modules”. Our rule is to not execute modules directly.

• These are the modules that return from the MKBANNER execution. We take defaults.

• This in-house (customer-created) module is pointed to an in-house SQL:/home/appworx/library/sql/Z_CASHNET_MPP_SEM_DROP.sql

• Let’s follow the CHAIN that will fire the previous module. Here is the GENERAL tab.

• We are not doing anything special with OUTPUT at this time.

• Let’s skip to the PROMPT tab. • We have a default of AUDIT (which means no

updating to MSU), then a date and dollar amount to be supplied at execution time.

• Note the “number” (placement) of the PROMPTS

• Back to the COMPONENTS tab. Here are four modules – rather copies of modules – which are now components of this chain.

• The module PROMPTS (parameters) refer to the order of the chain PROMPTS

• These prompts are evaluated within the sql; each module is fired in order as the CHAIN executes.

• You can require that a prior module complete successfully before moving on.

• This module has a CONDITION.• If we run this job with the chain’s AUDIT prompt, we want to

CANCEL the CHAIN, i.e. not execute the last module.• If we had used our POST prompt, the last module would fire

• Back to the CHAIN tabs. A SCHEDULE can execute a job as desired and also has several tabs.

• The SCHEDULE for the chain can have a different set of PROMPTS.

• This chain can now fire each day with certain criteria, and be fired manually during the day with other criteria.

• This CHAIN has no CONDITION, so we will skip that tab.

• We have created NOTES to help the Operators

• Several ROLES can execute this chain• People are assigned to ROLES• You can’t see more than four at a time; annoying

• Here is a complex chain for Financial Aid• Several modules are called from the main chain• Most of these modules are chains (sub-chains)• Each sub-chain has it’s own set of prompts, et al.

• Here is an expanded sub-chain.

• Each module within it has it’s own set of prompts, conditions, et al

• Here is another chain which has several conditions

• Recap for a Simple Chain:– Request and Submit MKBANNER to select and

“pull down” delivered BANNER modules

– Use that BANNER module as the only component for a chain (not required; MSU Shop Standard)

– Use default prompts (parameters), or supply those for your own institution

– Assign Roles, Permissions, Schedules, et al

– Fire at will

Thank you for attending!

Loretta Sampson, Systems AnalystLSampson@MissouriState.edu

(417) 836-8710

Missouri State UniversitySpringfield, Missouri

Questions?