Push Scenario Definition - General Data

Use the General Data tab of the Push Scenario Detail screen to modify data for a push scenario. You can define source, subscriber, notification, and activation settings.

Push Scenario Definition - General Data Tab

Basic Data

  • Scenario ID: Name of the push scenario
  • Alias: Alias of the push scenario
  • Mobile Application: Application to which the push scenario belongs

Source Setting

  • Source Type: Type of source object associated with the push scenario
  • Source Object: Drop-down list containing the available source objects for the push scenario
    Note: In order for an exchange object to be listed in the drop-down menu, the Push Relevant box must be checked in the Push Settings tab of the Push Scenario Definition screen.
  • Source Handler: Class handler associated with the source object for the push scenario. This is a non-editable field.

Distribution Setting

  • Distribution Type: Type of distributed object associated with the push scenario
  • Distribution Object: Name of the specific object associated with the push scenario, chosen by a drop-down list
  • Distribution Handler: Name of the class handler from the class repository that is responsible for updating the exchange table. This field is automatically filled when choosing the source object and is not editable.

Subscriber Setting

  • Subscriber Type: Drop-down list to choose if the push is sent to all users, users with active connections, or users defined in a scenario subscriber list.
  • Validity (Hr): Amount of time, in hours, of the validity of the data to be pushed to clients. When the time limit has passed, the data within the push scenario is no longer valid and will not be pushed to any more mobile applications.
  • Priority: The priority assigned to the push, with the default set to 0. The higher the priority setting, the higher the push is in the push queue. For instance, a push priority set to 0 is processed before a different push with a priority set to 5. For push instances with the same set priority or default priority, the pushes are processed in the order in which they were created.

Notification Setting

  • Email Notification: When checked, sends an email to all users affected by the push scenario.
    Note: User set up for email notification must be performed in the System Administration and Monitoring portal in the Administration - User Management panel before email notification is performed.
  • No Data Package: When checked, the data package, or push information, is not sent to the mobile device when the email notification is sent. A user must connect to the system and perform a regular fetch in order to retrieve the push information. In this way, users do not receive outdated push information if they are seldom actively connected to the system.
  • Email Subject: Subject, or header, of the email message
  • Email Message (140 chars): Body of the email message, limited to 140 characters. The limit is to support short messages to websites such as Twitter.

    A special variable, &OBJKEY&, is available for use in the body of the email message. This variable is substituted for the actual object identifier content during runtime and presented on the mobile Client.

Activation

  • Active Flag: When checked, the push scenario is in an active state. If unchecked, the push scenario is not performed.
  • Enable Push History: When checked, the push history table in SAP is populated. The push history table contains a list of users and the object keys pushed to those users.
  • Require Metadata: The metadata table is only populated for the push transaction when this option is checked. When unchecked, the default, the metadata table is not populated, saving Server resources.
  • Enable Fetch Callback: Fetch callback is used to augment data, in order to make it a two-step process. If implemented, an extra callback routine is invoked when Agentry is retrieving push messages for SAP. Note that you must enable the logic on the back end as well, before fetch callback will be possible. When information changes in SAP, a push is triggered and the distribution agent writes persisting information into the queue. This information is written to the database, which historically has created overhead to the system. The fetch callback avoids the overhead by not performing calculations in the queue; rather, it waits for Agentry to get the push. At that point, calculations for the fetch occur. In this way, the overhead of writing to the database is eliminated. An advantage to implementing fetch callback is that the copy is always fresh, as it is on demand. This eliminates obsolete copies. However, the disadvantage of using fetch callback is that calculations occur every time Agentry demands it.

Administrative Info

  • Created By: SAP user ID of the person who created the push scenario
  • Creation Time Stamp: Date and time of the creation of the push scenario
  • Last Changed By: SAP user ID of the person who last changed the push scenario
  • Changed Time Stamp: Date and time of the change to the push scenario

Example

The following sample screen shows that a push is enabled for all the transaction types defined in the list. For example, if a sales order is created and/or updated in the SAP back end, the changes for the transaction are pushed to the mobile client to the appropriate user without any transmit or trigger from the mobile client.



Parent topic: Push Scenario Definition