IUIE PDQ Publishing This document provides an introduction to publishing in the IUIE and specific instructions on how to publish a Pre-Defined Query report object, including:

How to publish PDQ report objects in the IUIE. IUIE publishing assistance resources

IUIE Interface: New report objects are published in the Test catalog. This catalog contains all new reports, new versions of reports, reports in development, and reports in the testing phase.

View ModeEach Catalog has two modes: View and Manage. Select the View mode tab to run reports only.

Manage Mode Manage mode is the default view for publishers and data managers. The mode can be changed by selecting the tabs at the bottom of a catalog’s index.. The Manage mode tab displays options for publishing and editing report objects and managing folders. Since reports are run in View mode, testers who are not publishers will not have the ability to toggle to Manage mode.

Navigating in Manage ModeTo open the Test catalog, Click the Catalog tab and select the Test Catalog link. To see the description of items in the Test catalog index, mouse over a folder image, report object, or method icon.

At the very top of the folder list is a method options menu:

Create Folder- places a new folder in the Test Catalog Create Report-opens the Key Information screen to begin creating a new report object.

When a folder is selected, its contents are displayed in the following order:

1. Method options menu (methods are indicated by a blue diamond) 2. Report Objects (indicated by the appropriate report-type icon) 3. Subfolders

To edit a folder, click on the folder label or icon to display folder management options:

Create Folder- creates a subfolder within the selected folder Edit Folder Details- Edit the folder name and descripton Move Folder Delete Folder

To edit a report object, click on the label or icon to display the test publishing functions. Remember that each report object displays different publishing options specific to the type.

9/8/06 8:57:00 PM 1

Edit Publishing Details: looks something like the following menu:

Key InformationDetailed Information (Fields) (Parameters) (Columns) (Custom Fields)Import MetadataSubject AreasAssign Object Level AccessAssign Row Level SecurityDisplay Access InformationOutput TypesHelp TextAssign to a Master Catalog FolderData Manager ApprovalChange Security TypeConvert to PDQ FileConvert to Indexed FileMove to Test- for GTT’s and Links onlyMove fo Prod for GTT’s and Links onlyVersion History

View Report Object Level Access Row Level Security Move Report Assign to Additional Folder Remove from Folder Copy Publishing Details Delete Report

Report TypesThis section summarizes the different report types that can be published in the IUIE.

Datagroup Reports

The icon represents a Datagroup report object. The key features are:

Users select a subset of data (the rows and columns to be returned)

9/8/06 8:57:00 PM 2

Query executes dynamically at run time Returns raw data; formatting depends on output type selection. Best for small result sets or to load into a spreadsheet for further analysis Source data refreshed on scheduled basis Users can choose whether to include column parameters, column headers, sql output, limit the number of rows to return and the output destination. Users can utilize Advanced button to write SQL for additional search criteria

Datagroup Template ReportsThe icon represents a Datagroup Template report object. Datagroup Templates are overlays to datagroups which means the publisher has pre-determined what columns will be returned and row selection criteria. The key features are:

Purpose of datagroup templates is to produce reports focused on subset of data from datagroup Users can further narrow the selection criteria by specifying additional parameters Query executes dynamically at run time, but not when sent to completed reports. Returns raw data; formatting depends on output type selection. Customize button accesses the underlying datagroup

PDQ Reports

The icon represents a Pre-Defined Query (PDQ) report object. The key features are:

PDQs contain raw data Returned data is determined by parameters users input Output format is pre-determined but user may be provided with formatting options Query executes dynamically at request time Information Publishers may join data from multiple datagroups

Indexed Reports

The icon represents the Indexed report object. The following information explains how this report object works:

Indexed report object is subset of a much larger report object Returns pages instead of rows and columns Because report is indexed on key fields, users select parameters based on those indexed Fields to

return a subset of data pages Output usually pre-formatted text or RTF Useful for very large reports from which a user may only want to see a few pages Advanced button may be available for more refined query options

Linked Reports

The icon represents a Linked report object. The following information explains how this report object works:

9/8/06 8:57:00 PM 3

Presents a metadata screen and a url to the report Document URL maintained by department providing the information Some online documents may require authentication before they can be accessed

Frozen Reports

The icon represents a Frozen report object. The following information explains how this report object works:

Frozen reports are summary reports grouped by department Cannot dynamically query against a Frozen report object Users can choose a version from provided list and whether to open or view the report in a browser or

save it to disk Pre-formatted report is returned No options for selecting subset of data

Publishing New ReportsSuccessful publishing in the IUIE is as simple as completing each publishing page as completely and accurately as possible. Because report objects in the Test Catalog have a status of TEST, all publishing details are editable. In contrast, the reports in the Master Catalog have a status of PROD and limited publishing options.

In general:

1. Check to see if the report object label name already appears in the Test or Master Catalog.

2. Complete description & detailed instructions information on the “Key Information” page.

3. Complete the Detailed Information page with parameter definitions and selection criteria.

4. View and verify the Access Information pages. Add Row Level and Object level access as appropriate.

5. Complete all information on the Output Types page.

6. Complete all information on the Subject Areas page.

7. Complete all information on the Assign to a Master Catalog Folder page.

8. Complete all information on the Help Text page.

Getting StartedIt is a good idea to check if the report object name already appears in the Test catalog or Master Catalog. You can use the Search function to check for both label and technical names.

Search Catalog searches for report objects in the selected catalog. The search catalog link is located just below the tabs, in a submenu for the Master Catalog and Test Catalog. By default, the search function performs the search in the catalog the user is in when Search is accessed. Search is not supported in My Catalog.

To publish a new Report in the IUIE:

9/8/06 8:57:00 PM 4

1. Click on the Catalogs Tab, and then on the Test Catalog link.

2. Click the Manage Tab at the bottom of the Test Catalog index.

3. Select “Create Report”.

4. Fill out all fields on the Create Report Page.

5. When finished, click the Next button.

A description of the fields follows the sample image of this page:

Type of Report Object: indicates the type of report that is being published.

Technical Name: The unique identifier for the report commonly referred to as “ro tech name”.

Label Name: is the descriptive label name for the report that will appear in the Master or Test Catalog’s index.

Data Group Name: If the report is a PDQ or a Datagroup Template, enter the GT that is the primary source of data and with the level of security that is to be set for the report you are publishing.

The information entered on the Create a New Report Object page will populate fields on the Key Information page.

Publishing Tip: Technical names should follow business naming conventions. Spaces are not permitted in the ro tech name. Only letters, numbers, and underscores are allowed. If you are publishing a PDQ, do not include the .sqr extension in this field: use the technical name only.

9/8/06 8:57:00 PM 5

Key Information1. Fill out all the fields on the Key Information page.

2. Click the Save button.

A confirmation of the new report is returned, and the new PDQ will be displayed in the Test catalog index, in the Not Assigned to Folders folder.

A description of the fields follows the sample image of this page:

Publishing Group: lists available publishing departments, determined by the publisher’s access.

Application Code: determines the subject codes for the report, as well as the security roles available to be assigned to the report.

System Code: In the case of Frozen Files and PDQs, this must match the location of the physical file.

Security Type: determines access information. May default to row level.

Refresh Frequency: this field is read from ie_ro_t table in Gen1PRD. The date appears in the Metadata section, at the top right.

Publishing Campus: This field is used to determine the appropriate data managers for access

requests.

Publishing Department: if your department is not listed please contact us at through the Feedback form in the IUIE.

Security Type: determines access information

Description: describes the contents of the report object. This information is often very helpful to users of the report.

Detailed Instructions: provides users with information unique to the RO.

9/8/06 8:57:00 PM 6

Publishing Tip: The descriptive information included in the metadata can determine how effectively IUIE users will understand the report. Include what can be obtained from the report, and how to use it effectively.

Publishing DetailsThe Edit Publishing Details menu, which opens in the browser after the Key Information page is saved, displays links to the publishing pages. There isn’t a certain order that needs to be followed when completing the publishing details.

Briefly, to complete the Publishing Details for a PDQ:

1. Assign a Subject Area.2. Assign the PDQ to a Master Catalog Folder.3. Select the Output Types.4. Enter in Output format information if .rtf is selected.5. Verify and assign access groups.6. Enter Help Text1. Complete Detailed Information.

Subject AreasUsed in the IUIE to determine the data manager responsible for the data contained in the report. The DSS team recommends assigning a subject area first simply so it isn’t overlooked. Some other publishing options, such as what security groups are available, rely on information supplied in previous fields. For example, the Application area determines what subject codes are available, and selecting the subject code helps determine the selection of user groups that can be assigned to a report.

To Assign a Subject Area:

1. Click on the Subject Areas link.2. Check the box next to the appropriate selection.3. Click the Save button.

Assign to a Master Catalog FolderWhen a new report is successfully created from the Create Report option, it is automatically placed in the Not Assigned to Folders folder in the Test Catalog index.

To move the PDQ to another folder:

1. Click on the Assign to a Master Catalog Folder link from the Publishing Details menu.

2. Drill down and select the folder that should contain the report.3. Click the OK button. A Confirmation message will appear.

The Test catalog index will open the folder in which you saved the report. In this example, the PDQ Carol Test appears in the Developer/Publisher Info folder. If a subfolder is selected, the main folder’s contents will be displayed and the name of the selected subfolder will be highlighted. Beneath the highighted folder will be the report you just saved.

9/8/06 8:57:00 PM 7

Once a report is saved to a folder, two new method options appear, Assign to Additional Folder, and Remove from Folder. Remove from folder places the report back into the Not Assigned to Folders folder if the report is assigned to at least one folder. If a report is assigned to multiple locations, it is simply removed from the selected folder.

Publishing Tip: An Assign to Folder link is also available from the method options menu. If you have initiated a new report from the Copy Publishing details method option, it will be placed in the Test Catalog and located in the same folder as the original report.

Output TypesOutput Types determine which format or application a PDQ returns. Multiple output types can be selected, but only one specified as the default.

To Assign Output Types:

1. Click on the Output Types link.2. Check the box next to the appropriate selections.3. Make certain only one output type is chosen as the default.4. Click the Save button.

Barr Printer Output TypesBarr Printing is available on the parameter entry screen of PDQs in the master catalog, personal catalog, test and production. Under Output Destination is a radio button that allows output to be directed to a BARR printer. Adjacent to the radio button is a text input field that allows entry of a 4 character BARR printer ID.

Users are expected to know the BARR printer ID's that they need to use. PDQ's default to a 4712 form, but PDQ publishers can define a field named "BARRFORM" that will override the default. The PDQ publisher must supply the BARRFORM value as a default, or allow the user to enter the field.

Publishers can direct their PDQ output to Special forms BARR Printers. These are forms such as payroll checks, Degrees, official watermarked documents, etc. Often, a "special" printer with enhanced capabilities (software and drivers) is needed to process special forms such as these.

A Publisher determines whether a PDQ can produce BARR output by the way the BARRFORM parameter is defined to specify PDQ output types. The SQR must be written to recognize the BARRFORM parameter and also produce the appropriate output format. In the IUIE, A PDQ will contain the output destination radio button, set to "BARR Printer" by default. A user can direct output to a BARR printer by specifying a four-character BARR printer code in the associated text field.

Currently, PDQ BARR printer output defaults to form 4702. This can now be changed so that users can specify a special form. Publishers can do this by creating a "BARRFORM" parameter and setting the default value for the parameter to the form number to be used

If the publisher allows BARRFORM to default, or sets it in a HIDDEN parameter, the user will not be able to choose the BARR Printer Form; they can only choose the form defined by the PDQ publisher. The user won't see a reference to a

9/8/06 8:57:00 PM 8

BARR Printer Form. Users will be able to direct output to a BARR printer, but the output will use the form specified in the BARRFORM parameter.

If the PDQ is to produce multiple output formats that will need different BARR forms, the BARRFORM parameter can be defined as a DROPDOWN list or TEXT field. A DROPDOWN would allow the user to select only those forms which the PDQ supports from the provided list. The TEXT field would allow the user to specify any BARR Printer Form. If the publisher defines the BARRFORM parameter as a text field, the IC can enter any form number. This implies that the PDQ can generate all possible BARR Printer output formats.

For more information, see the SQR Developer’s Guide.

Output FormatPDQ page layout options are possible if the PDQ returns the Word-RTF output type. An Output Format button on the Output Types publishing page allows formatting specifications. The button is on the line with the Word-RTF option only, and has no effect for other output types. The button is located here because PDQ's need not specify Word-RTF as an output type. Only those PDQ's that use Word-RTF need to have the extra information published.

In addition, a link on the Edit Publishing Details page for PDQ's if page layout information has been stored is located after the Detailed Information link. RTF conversion of PDQ output will be done as output is returned to the browser.

Help TextThe help text is displayed to the user as metadata. We strongly recommend that you enter detailed and meaningful help text. Feel free to use html tags to format the text.

Security InformationThe next several publishing pages, Assign Object Level Access, Inherited Row-Secured Groups, and Change Security Type links are conceptually related to how PDQ security works.

General PDQ SecurityAt the simplest level, a user security group will control access to the PDQ in the IUIE. Lookup functionality will be available to see what tables are referenced by any given SQR, View or Datagroup, but users will not necessarily need to be able to access each underlying table. A proxy account will be used to execute the PDQ against the DSS1PRD database, implementing any row-level access assigned to the user submitting the PDQ.

The proxy accounts are created when the user’s account is setup. Existing users’ proxy accounts will be created on the day of the release on Sunday, June 5th. This proxy account, (<USER>_PDQ) will be invoked when a user clicks the “RUN” button to execute a PDQ.

The <USER>_PDQ account will have access to all tables in the DSS1PRD database, which is the reason users no longer need access to all the datagroups used in the PDQ. However, no users will have direct access to the <USER>_PDQ account. This allows a separation of the PDQ from the underlying data.

9/8/06 8:57:00 PM 9

From a publishing perspective, row-secured groups will still be assigned to row level report objects. From a data manager perspective, row level values will be assigned to users directly (via the Collections catalog) instead of placing them in an RL group.

Using a table-scanning utility, the IUIE will know if the underlying SQR references row level datagroups.

If row level datagroups are found in the SQR:

The Security Type field in the PDQ Key Information page will default to the Row Level selection. This can be modified as needed. If there is a mismatch between the assigned security and the results of the table scan, it will be noted on the Edit Publishing Details page and a suggestion made to reconsider the security type.

Assign Object Level Access-Select the appropriate user security group from the list. The list of available user groups in the Assign Access to Object Level Groups function will be populated with only RRL user groups if the scan finds row level data groups in the SQR.

Inherited Row-Secured Groups -The Edit Publishing Details page will display this link if row level security is found by the scanning utility. The page will list the row-secured columns inherited from the tables used in the SQR. Values for row level columns will be assigned for each application area (that makes use of RL security; ATHL, ADM, FA, SF, and SR).These are the row-level values that will need to be assigned to an individual user in order to run the PDQ. While publishers do not assign user access, this information may be needed by data managers.

Change Security Type Link – allows a publisher to change the security type of a PDQ. Changing the security type removes existing user group access for the PDQ (in test and in production). This will prevent the users from being able to access the PDQ until new user group access is assigned and approved. This functionality is intended to be used to update the PDQ security information manually if any security changes are made to the datagroups referenced by the PDQ.

Data Manager ApprovalOnce the report object publishing is complete, click on the Data Manager Approval link to review the access assigned and inherited by the PDQ. Submitting the form sends an email to the data managers.

Publishers may need to confer with a Data Manager or lead developer to determine the user group to select for access control. If none of the existing user groups seem appropriate for control of the PDQ, publishers should work closely with a Data Manager or lead developer to create or request a new user group.

Detailed InformationThink of parameters as the column references in the ‘where’ clause of an sql query of the underlying data group.

To define field parameters:

1. Click on the Detailed Information link.2. Click the Add Button.3. Fill in each field on the form.

A sample of the Add New Parameter page

9/8/06 8:57:00 PM 10

Defining Field Parameters

Label- Enter a Parameter Label. This is the Descriptive name for the parameter. If the parameter requires a specific format, this should be included in the description. (Ex: Transaction Date (MM/DD/YY))

Widget Type- Select a Widget Type from the drop down list.

The image below displays the widget types a publisher can choose:

9/8/06 8:57:00 PM 11

Widget Type Specifications Checkbox A checkbox is rendered as the parameter label followed by a

checkbox. Multiple checkboxes can be checked. Currently, each checkbox is independent of all others, because they are uniquely named.

Date- a format MM/dd/yyyy.

Date Time:- MM/dd/yyyy HH:mm:ss, the date format including hours minutes and seconds.

Dropdown- a set number of selections displayed in a vertically scrolling box, displaying only the selected value and dropping down all possible values. Values are defined using the Define Widget values button.

Hidden The checkbox is non-functional. Only the "Hidden" widget type is used to render hidden fields.

List box- A list box is like a dropdown where a set number of selections are displayed in a vertically scrolling box, instead of displaying only the selected value and dropping down all possible values. A list box allows for multiple value selections using "ctrl click". Only the values coded in the list box can be selected, no new values can be typed. Values are defined using the Define Widget values button.

Radio Button returns one selected value. Values are defined using the Define Widget values button. Of the list of possible values, Radio buttons only allow one to be checked. When one is selected, other are deselected.

Text Field- A text field is a single line text input widget.

Text area -is a multiple line text input widget. Each of the text input widgets can have a maximum size specified which determines how many characters may be typed.

Heading- Heading widget types may be used to insert explanatory text or instructions on the report form.

On the Detailed Information Page, the next several parameters define how the data will be accepted:

Numbers Only- choose Yes or No to restrict this parameter for numeric text only.

Mandatory- choose Yes or No to make this a required parameter. For larger queries, it is a good idea to have at least one Mandatory parameter to reduce long run times.

Uppercase- choose Yes or No to convert input to an uppercase parameter. If you select this feature, make sure your SQR (PDQ code) is expecting uppercase values.

9/8/06 8:57:00 PM 12

Accepts Wildcards- selecting Yes will place a ‘wildcards allowed’ link to the right of the parameter on the parameter entry page, indicating to the user that wildcards are accepted. This feature is very handy for specifying patterns such as account numbers or names.

Maximum Number of Values: this determines the maximum number of values that will be accepted for this parameter. If any number of values can be listed, type “999” in this field.

Default Value(s): The value that is initially displayed on the parameter entry page.

Display Size: this determines the width of a field provided. These parameters can simplify your SQR by performing simple parameter validation. DSS suggests a standard size of 25 characters; the suggested maximum is 30 characters. Limiting the size of the text box will prevent the valid values button and wildcards allowed link from scrolling off of the report form. It also a good idea to limit the display size to the maximum size of the parameter value in order to avoid user error. For example, a field that requires a date in the format MM/DD/YY can have a display size of 8 to ensure the user doesn’t enter a value like 01/01/2002.

Description (if not a column)- enter a description. For example, a PDQ parameter might be inst_cd. This is a column, so the description would be retrieved from the column description of the datagroup specified in the underlying Datagroup Name field. You might have another parameter, include_sidn. This is a yes/no field, which tells the PDQ to include the SIDN in the output. Because include_sidn is not a column name, you would enter a description to tell what this parameter means to the PDQ. The publisher might already have updated this field, in which case, the functional staff might want to proof-read for functional understandability.

Datagroup name (if a column)- enter the datagroup name.

Valid Value Synonym is the name which will be used by publishers to indicate which valid values to return for a field when the valid values button is pressed on a publishing or parameter entry page. The Synonym Name is used to uniquely identify a code-description pair of columns from a Valid Values table. Each use of the synonym results in the same list of valid values, no matter which field is assigned it. The actual name for the synonym is up to the Publisher.

For consistency, the DSS team suggests using the Code Column Technical Name. If the parameter accepts only certain values, and if the values come from a table in the corresponding DSS instance, then the IP can choose the desired Valid Value Table from the list of tables defined in the drop down list.

There is only one copy of the synonym. Any publisher can change it. If it is changed, it changes the valid values for EVERYONE. If a publisher wants a different list of values from a table without affecting everyone that uses a synonym, they must create another synonym.

View Synonym-To view information about an existing Valid Value table entry, choose the Valid Value entry from the drop down list and then click on the View Synonym button.

Add Valid Value Synonym-The Add Valid Value Synonym button allows the addition of a Valid Value Synonym table name. Use this feature if the Synonym table name is not provided in the drop down list.

The Valid Values Synonym Page that displays will look something like:

9/8/06 8:57:00 PM 13

Table Name is the DSS table that holds the valid values

Table Description Text can be added to help clarify the intent of the synonym.

Code Column Description, Name|Pattern The code and description columns are any two columns in the table. The description column is displayed on the valid values page, and the code column is the value that is sent to the report object field

Schema Name- The Oracle schema that contains the table name.

Optional Where Clause - the where clause limits the rows that will be selected from the table.

Prompt for Lookup if checked, a "Lookup Values" button is painted on publishing and parameter entry pages instead of a "Valid Values" button. When pressed, an intermediate lookup values page is presented which allows the user to

specify which codes/descriptions are desired.

Optional Where Clause The Optional WHERE Clause deserves a little in depth explanation. Normally, a valid values query will return ALL rows in a table. The WHERE clause limits the rows that can be selected from the table.The publisher can specify a where clause that will be appended to the valid values query, which restricts the rows to the subset that meets the conditions set forth in the where clause. For example, If a table has all campuses in it, but the publisher wants the valid values  to be restricted to Bloomington, they can enter a where clause that returns only those rows relevant to Bloomington.Essentially, IUIE executes a query that looks like:

select code_column,description_column from schema.table_name where (where_clause to get the list of valid values).

With lookup values, the user specifies additions to the where clause that restrict the output, resulting in a query that looks like:

select code_column,description_column from schema.table_namewhere where_clauseand ( code_column like user_entered_criteria user_specified_operator description_column like user_entered_criteria)user_specified_operator is either "and" or "or"

9/8/06 8:57:00 PM 14

Publishers should choose a code column with unique values that contain no embedded blanks, and that are in 1-1 correspondence to distinct descriptions. There is no error checking, so care should be taken

Prompt for Lookup:   Lookup values is an extension of the valid values where clause also, but allows the user to restrict the rows returned by specifying  a code column pattern and/or  description column pattern of the list.

Previously, users had to find their selections from possibly dozens of choices. With the introduction of the intermediate lookup values page, users can reduce the number of selections presented on the valid values page to just those that match the criteria they enter on the lookup values page. Those criteria are patterns that the code and description fields of the valid values table must match. The patterns are the same as those possible in text fields with wildcards.

PDQ Mailing FunctionalityTo take advantage of this functionality, a PDQ developer must:

Publish a PDQ (SQR, Perl, or Sh) that produces an IUIE mailing request file. Specify the "Mail" output type for the PDQ. Insure that the intended users are part of the IE_MAILING_R User Group.

If the "Mail" output type is enabled for a PDQ, a "Mail" output type radio button appears on the parameter entry screen.

If the user of the PDQ is a member of the Mailing user group (IE_MAILING_R), then a "Mailing" output destination radio button appears on the PDQ parameter entry screen.

Selecting the MAIL output type causes MAIL to be supplied to the SQR (or Perl or Sh) as the output type. The PDQ code must be written to recognize the output type requested, and generate appropriate output. If the PDQ can only generate a mailing request, then "Mail" should be the only output type, and the PDQ code can ignore the output type being passed.

MAIL output is formatted text, so it can be directed to any output destination (Browser, Completed Reports, Printer, and Mailing).

By directing output to a destination other than mailing, the output produced from the specified PDQ parameter values can be verified/validated before actually performing a mailing.

When satisfied that the specified PDQ parameters generate the appropriate set of records, the resulting mailing request can be sent to the "Mailing" output destination to cause mail messages to be sent. The user will be informed with a browser screen similar to the one for sending to completed reports that their request has been routed to the mailing queue.

When the mail queue processes a mailing request, the address(es) specified in the NOTIFY section is informed of completion through an email notice which includes information on the number of mailings done, the type of mailing (create, mass, merge), and RO metadata sufficient to recognize which mailing request is being referenced. The same information in the notification email is included in the message text of the IUIE job log.

The Mailing User Group, IE_MAILING_R, is used to enable mailing functionality. It is not a typical IUIE user group. It is used simply as a list of people who have been granted mailing privileges. It

9/8/06 8:57:00 PM 15

should not be assigned as an access group for a report object. A user must be a member of this group for the “Mailing" output destination to appear as an option on the PDQ parameter entry screen.

Users not in the mailing group can still run the PDQ and see the mailing request file that is generated, they just can't send the request to the mailing queue to cause mail to be sent.

PDQ Coding (SQR, Perl, sh)As with DataExtract, there are three mailing functions available to the publisher of a PDQ:

1) Create Mailing List will be done if the MAILING_LIST section is included.

IUIE only sends the initial creation request to Majordomo. All subsequent management of the list is achieved through direct interaction with Majordomo through commands sent through email.

2) Merge Mail will be done if a FIELDS section is supplied.

Each mail of a merge is sent individually, since no two Merge Mail's are necessarily identical. The ADDR section supplies values for variables declared in the FIELDS section. Variables of the FIELDS section can be referenced in the SUBJECT and BODY sections by prefixing "$" to a FIELDS variable name.

3) A Mass Mail will be done otherwise.

All mails in a mass mail are identical, so the recipients can be grouped into the BCC header (currently in batches of 100). Use of BCC insures that the recipients are not aware of others who (or how many) received the mailing.

IUIE Mailing Request File Sections An IUIE Mailing Request is simply a series of sections:

Each section is a section header line, followed by the value lines to be associated with that section.

A section is terminated by detection of another section, or the end of the file. The values supplied for a section must begin on the line FOLLOWING the section

header, not on the same line as the section header. The section header itself shouldn't have leading/trailing blanks, because an equality

test is being used on the whole line. The order of the sections (FROM, TO, SUBJECT, etc.) is important: The most

important thing about the order of sections is to place the ADDR section last.

Because the file is read line by line to retrieve section values, placing ADDR before other sections would require the entire ADDR section to be read once for each section that follows ADDR. Since ADDR is typically the longest section, that would be very inefficient. However, any section order will work. If the ADDR section is short, the order of sections is unimportant.

9/8/06 8:57:00 PM 16

Section Summary Here is a summary of what sections may be supplied, and the types of values expected.

Mandatory

The following table shows all mandatory sections: all generated emails should identify themselves, their content, and recipientsFROM If a FROM section is not supplied, recipients of the mail will not know who sent the

mail.SUBJECT The SUBJECT section can contain references to names specified in the FIELDS

section, just as in the BODY section. This feature allows the Subject: line of generated emails to include values from the current ADDR record being processed.

BODY In the BODY section, the value of a column in the current ADDR record can be referenced by prepending "$" to a name listed in the FIELDS section. like: Dear Student $student_id, Your $course_number in $building room $room has been changed to meet at $meeting_time.

ADDR The first column of an ADDR record must always be an e-mail address column. This value is used to supply values for the "To:" header of the generated e-mails.

ADDR section records are delimited by newlines. Columns of ADDR records must be delimited by tabs. Tabs and newlines in ADDR section column values must be coded as Perl

escape sequences. In the future, we may allow arbitrary delimiters to be set with

ROW_DELIMITER and COLUMN_DELIMITER sections, but for now, they are constant

There should be no column header generated for the ADDR section. The ADDR section should only contain valid data.

ADDR section columns can contain Perl escape sequences to aid in formatting output.

Perl references can be consulted for advanced usage, but to summarize the most useful:

Escape Sequence Effect\n newline\t Tab\Odd Octal representation of an ASCII character (d stands for digit)\xdd Hexadecimal representation of an ASCII character\l Make the following character lowercase\L ... \E Make all characters until a \E lowercase\u Make the following character uppercase\U ... \E Make all characters until a \E uppercase\Q ... \E Take everything between \Q and \E literally (turn off

interpretation of escape sequences)

9/8/06 8:57:00 PM 17

OptionalThe following table shows Optional sections, which determine how the mailing request is processed:MAILINGLIST If present, it specifies that a mailing list should be created and allows the mailing list

name to be specified. Not used for Mass and Merge mails. REPLYTO Mandatory with MAILINGLIST, because it informs majordomo of the list owner.

It is optional for Mass and Merge mails. But if supplied, REPLYTO determines the addresses that will receive replies from recipients of the mailing.

FIELDS If present, specifies that a Merge mail will be done, and the order of fields in the ADDR section. The list in the FIELDS section can be compared to a column header for the records in the ADDR section.

Names in the FIELDS Section are used as variable names, so they should not contain embedded blanks e.g., student_email might be a good substitute for "student email".

FIELDS names should begin with an alphabetic character. FIELDS names are case sensitive, so be consistent. It is probably best to use the technical name of a column in the FIELDS

section. But, since they are just stand-ins, they can be anything that is distinct.

NOTIFY Notification e-mails contain the count of mails that were sent to addresses listed in the ADDR section. Notification e-mails are not part of the count.

The following Sections should never be specified:

AUTH not currently used, so it is unneededTO is always taken from column 1 of the ADDR section, so it should never be specified

Master CatalogManage mode is the default Mode for all publishers. The current mode is indicated by the tabs at the bottom of the Master Catalog. Manage mode displays options for editing and managing folders and shortcuts to report objects. Folders and shortcuts can be created, renamed, moved, or deleted. On the right, descriptive text is included.

Because report objects in the Master Catalog have a status of production, some publishing details will not be editable. Publishers will have to create a new version of reports in Test if significant changes need to made.

Managing Production ReportsClick on the Catalog tab, then the Master Catalog link to open the Master Catalog. Place the cursor over the folder image or report object icons to see the description of the associated item.

At the very top of the folder list are two methods used for publishing:

Create Folder- places a new folder in the Master Catalog Create Report-opens the Key Information screen to begin creating a new RO.

When a folder is selected in Manage mode, its contents are displayed in the following order:

9/8/06 8:57:00 PM 18

1. Management options (indicated by a blue diamond) 2. Report Objects (indicated by the appropriate report-type icon) 3. Subfolders

To edit a folder, click on the folder label or icon to display:

Create Folder- creates a subfolder within the selected folder Edit Folder Details- Edit the folder name and descripton Move Folder Delete Folder

To edit a report object, click on the label or icon to display the prod publishing functions:

Edit Publishing Details: Displays something like following menu on the right. Remember that different RO Types will offer different options. IP’s will recognize these options from the former Prod Edit Publishing details menu; they have the same functions.

Create a New VersionKey InformationDetailed Information: This function may display buttons to further modify:

Fields ColumnsParametersCustom Fields

Subject AreasAssign Access to GroupsOutput TypesOutput Types and RetentionHelp TextAssign to a Master Catalog FolderData Manager ApprovalChange Security TypeConvert to PDQ FileConvert to Indexed FileVersion HistoryArchive This Report Object

Run Report View Collection Access Move Report Assign to Additional Folder Remove from Folder Copy Publishing Details – from the selected report to Delete Report

IUIE Publishing ResourcesSend publishing and SQR questions to IUIE-REQUEST.

Detailed information about publishing in the IUIE is available at the following url:

http://www.indiana.edu/~dss/Services/Documentation/

9/8/06 8:57:00 PM 19

This documentation, as well as other IUIE documentation is also available in the IUIE from the Master Catalog/IUIE folder/ Developer/Publisher Info folder.

Information Environment Overviewhttp://www.indiana.edu/~dss/Services/Documentation/Information_Environment_Overview.doc

Information Providers Reference Guidehttp://www.indiana.edu/~dss/Services/Documentation/IP_Publishing_Reference.doc

Information Environment Project Methodologyhttp://www.indiana.edu/~dss/Services/Documentation/Project_Methodology.doc

SQR Developer’s Guidehttp://www.indiana.edu/~dss/Services/Documentation/SQR_Developers_Guide.doc

9/8/06 8:57:00 PM 20