Concepts

This information provides an overview of important IPF portal development concepts.

Content version

A content version is a package of portal application code. It includes the pages, layouts, styles and other components used by IPF portals. New application features and issue fixes from Infor are delivered in updated content versions. It is important to have a standard procedure on a periodic schedule for implementing new content versions.

New content versions are imported using the Portal Manager. They are then activated for use in selected portals. This allows you to run different portals on different levels of application code. For example, you could keep production portals on one version and update test portals to a newer version.

Personalizations and customizations for your portal are made in content versions. Infor content versions cannot be modified directly. Instead, you must enable a portal for development; create a custom content version with a unique originator, which identifies the content as your own; and then modify the content as needed. The custom content version contains the customized components, which override the standard content version components.

Originator

Each portal component is associated with a single originator. This originator indicates the organization, product, or project that created the component. A set of components tagged with the same originator all come from a single source. For each component, names are unique within the originator. During development, entries are automatically associated with the editable originator.

Feature

A portal feature indicates the name of a set of functionality. The Default, Customer Portal, Vendor Portal, and Reseller Portal Additions features are code sets provided with the portals. The Default feature is the only code set currently provided with the Infor Service Management portal. You can also add custom features.

When you have multiple portals, the Default feature is assigned to components that can be used in all portals. The other features are assigned to components that should be used only in a specific portal. For example, the Announcements page layout is the same in all portals, so it is associated with the Default feature. The On Time Delivery page layout is used only in the Vendor Portal, so it is associated with the Vendor Portal feature.

When you create a custom content version, you must specify a feature to assign by default to any new components created during development. In most cases, you can specify Default as the feature to use, for these reasons:

  • Typically when you create a component, you start with an existing component and either copy it or save it with another name. Any time you start with an existing portal component, the component retains its original feature, regardless of what you specify as the default feature for the custom content version. Only when you add a new component does the specified feature get assigned to the component by default.
  • You can review and change the feature for a portal component in the editable originator at any time.

In order for the components of a particular feature to be visible on the portal website, that feature must be included and active in the portal content. For example, if you create a custom content version for the Vendor Portal, but activate only the Default feature, any components that are associated with the Vendor Portal feature will not be visible on the website. You must add and activate the Vendor Portal feature.

Feature dependencies

In the Portal Manager, you can create or update feature dependencies for the current editable originator. For existing dependencies, this information is displayed in the Portal Manager:

  • Feature Name: The feature that has the dependency.
  • Originator: The originator that has the dependency.
  • Depends on Feature: A list of features that must be activated for the above originator and feature to be activated.

Enabled/closed for development

In the Portal Manager, you can enable and close the portal for development, and you can enable and close content versions in that portal. These are separate actions.

Enabling the portal for development makes certain tools available for use in the Portal Manager. When you enable the portal for development, you must at the same time select or create a custom content version, which allows you to modify the portal content. When you close the portal for development, you can no longer work on content versions in the portal, even if the content versions are still enabled for development.

Closed portals can be reopened by selecting an existing active content version or by creating a new one. A closed content version can never be reopened.

Content activation

Content activation allows you to apply new content versions to a portal. These are guidelines about activating and deactivating content:

  • The list of available content versions is built from the available content versions for which the minimum IPF version required setting meets the portal IPF version.
  • You cannot have two or more originators with the same priority and active content.
  • You cannot activate a feature that is dependent on a feature that is not already selected to be active.
  • For each component type, two components with the same name cannot be active at the same time. If there is a conflict, it is resolved using priorities. Larger numbers have higher priority. If the conflict is not able to be resolved, an error message is displayed.

During development, if you are creating a component for an active feature, the new component is also set to active. If the feature is inactive, the new component is not set to active. Generally, it is best to work with active content when working on development projects. Otherwise, you cannot test your new components.

These are examples of how you might use content activation to achieve specific development goals:

  • You need to load multiple versions of the same component into a portal, so they must have different originators. For example:
    • Two separate products: The content of two completely separate products, such as Customer Portal and Vendor Portal, are loaded at the same time. Only one can be active at a time, therefore, during development no effort is made to avoid conflicts among components. The originators could be Infor Portal and MyCompany Portal.
    • Two separate product versions: There are two versions of a single product active at the same time. Bug fixes of one version cannot be mixed with bug fixes of a different version, in case they are accidentally loaded into a portal. The originators could be Infor Portal 9.00 and Infor Portal 9.01.
    • Modifications: You need to copy and modify some components, such as pages, layouts, and help files, and then make your modified version override the original version. You can add the modified versions in a separate originator, for example Infor Customer Portal 9.00 ICS Mods. You can then activate both versions, but set the modified version to a higher priority. When the portal finds two versions of the same component, the version with the higher priority is used.
  • You need to have one or more portions of a single product turned off, so you put them in separate features. For example:
    • The product includes a pre-login catalog browsing feature, but you cannot provide Internet access to your catalog without making users log in first. Pre-login pages can belong to a specific feature, which you do not have to activate if you must exclude that functionality from your portal.
    • The product has a set of components that are reusable and other sets of components that can be turned on and off. You can create a feature called Base that contains all of the reusable components. Other features can be made dependent on Base, so they always have the supporting components that they need.
    • The product includes a Down for Maintenance page that is displayed occasionally. You can structure the features so most of the product can be turned off and the Down for Maintenance page can be turned on.
    • There are multiple versions of the same feature from different originators. For example, there are two configurators for order entry, one from Infor and one from Partner. Some users need one version and other users need the other version. You can create a dependency requiring that the order entry feature has a dependency on the configurator feature. Then activate the configurator feature from the originator of your choice.

Content security

Because there is inherent risk in exposing data to and receiving data from client machines, the IPF portals are built to limit exposure to the client. To help you maintain the security of custom content, we provide best practice recommendations in the areas of layout and session variables, alert events, data changes, and server-side only properties.

Note: This information applies to IPF 4.x content. Information about migrating IPF 3.1 content to use this new protocol is provided in the Infor Portals Migration Guide.

Session and layout variables

When developing content, you may need to include sensitive data in a session or layout variable, which should not be visible to the client. To make this data secure, you must use the ServerLayoutVariables and ServerSessionVariables provided by IPF. Any data that uses the IPF ClientServerLayoutVariables or ClientServerSessionVariables cannot be trusted, because the client could modify the data manually before sending it back to the server. Also, any data that uses the IPF ClientLayoutVariables and ClientSessionVariables should not be trusted, since the client could modify it manually.

Alert events

During development, you may also use alerts that are sent back and forth between the client and the server. Alerts that originate on the client cannot be trusted, because the alert and the data in the alert could have been manually generated on the client. By default, any alert created on the client is not trusted. This means that alert handlers registered in the server-side scripting are not automatically run when the alert is sent from the client.

When your application must accept a client-generated alert, you can add a call to context.RegisterClientAlertsFor() in the server-side script in OnScriptInitializing(). This allows the client-generated alert to flow to the server for processing in the server-side alert handler.

Note: Care must be taken in the server side to appropriately process this data. For example, if the server has a change to the user's name, it is probably okay to get this in a client alert. The logged in user is allowed to change their name, so the server side can accept this data. However a potential bad design would be to put the price of an item in the client alert and use that price when adding to the cart. The client could manually generate this event and add an item to the cart with a low price. Similarly, sensitive data that the user must not see should never be put into an alert, even if it is sent from the server, because all alerts pass through the client so that the data can be viewed. Portal alerts are used as a notification system, not a secure data channel.

When an alert is sent from the client that matches a name in the registered list, the registered server-side OnAlert() handler is called. If the name does not match, the serve- side handler is not run. If the alert was sent from the server, the OnAlert() handler is run regardless of whether or not it is in the list of client alert names.

Note: The server-side alert handler will still honor the parms.StopServerSideHandler() API call from the client. However, regardless of this StopServerSideHandler setting, if the alert did not come from the server and it is not in the list of accepted client alerts, the alert will not be processed by the server.

OnAlert() handlers in the server-side scripting also will not fire for a specific alert if the alert was altered by a client script. Alerts are considered altered by client script that passes along an alert in one of the following methods:

  • context.Alert...(context.GetEvent().GetName());
  • context.Alert...("eventname");

Alerts should instead be passed along in this fashion to not be considered altered:

  • context.Alert....(context.GetEvent())

Data changes

For data changes, it is best to limit the fields that can be modified by the client, and validate the changed values when applicable. Again, the name change example applies here. You can allow the client to change their first name and then just validate that the correct characters are contained in the updated name on the server side.

A scripting API is provided to indicate if a component is modifiable by the client.

  • IPFPropertyI -> ClientModifiable: Initialized to the value of the Enabled check box in the Layout Editor. This is available only in server-side scripting.
  • IPFUnboundComponentI -> ClientModifiable: Initialized to the value of the Enabled check box in the Layout Editor. This is available only in server-side scripting.

The initial value of IsClientModifiable is set to the valued specified by the Enabled check box in the Layout Editor. When server-side scripting changes Enabled, the IsClientModifiable flag is also changed to the same value by the IPF architecture. To allow client modifications when Enabled is not true, server-side scripting can explicitly set the IsClientModifiable flag to true. When IsClientModifiable is true, the architecture assumes that data changes from the client are expected and allowed on this field. For these fields, the existing scripting implementation should already be doing validation on the data, since changes are coming from the client. When client scripting sets Enabled to true, if IsClientModifiable is not true, any data change made in the Enabled component is dropped at the server. If the client scripting makes a data change to a component or property and IsClientModifiable is not true, any data change made is dropped at the server.

The IPFDropdown FDF has additional values that can be specified. These additional values go into the target properties causing a data change. These changes happen on the server side, so IsClientModifiable does not have to be set to true for these components.

Server-side-only properties

For server-side-only properties, it is best to limit data passed to the client to only the data that you want visible to them. By default, the properties available on the client side are restricted to only those used by the layout. All other bound and unbound properties associated with the layout's bound collection are not returned to the client and are not available in client side scripting. The following server-side scripting APIs allow properties not displayed in the layout to be made available in client-side scripting.

  • context.AddClientAvailableProperties (array of added property names): Properties in this list are made available to the client scripting. If a name is supplied that is not a valid property, an exception is thrown. If a property name is supplied that is displayed in the layout, it is ignored (since it is already visible to client scripting). This API is available only in the LayoutInitialized event handler.
  • context.ClientAvailableProperties: Returns the list of properties that are available to the client scripting.

This does not apply to unbound components, as they are always in the layout and available to the client scripting. Setting IsClientModifiable to true on a property that is not client-visible has no effect, since the property is not visible on the client.

Managed database schema

For MSSQL data sources that point to databases for certain types of data—such as portal email, tasks, and knowledge content— the databases must use specified data store types and managed schema to support those data store types. More information is provided in About managed schema in MSSQL databases.