Home
Reference
Shopping flow URLs
WebSphere Commerce shopping flow URLs are organized by subsystem.
Scheduler URLs
The server subsystem consists of functions that are associated with URLs that are run by the scheduler.
AddBroadcastJob
This URL schedules a broadcast job for the WebSphere Commerce scheduler.

Reference
- WebSphere Commerce API reference
  WebSphere Commerce exposes two main programming APIs. The first and newest API is a REST interface, and most new classes are exposed here. The legacy Java API also contains new classes not suitable for REST, and can be browsed in Javadoc format.
- Cross-reference of data beans, EJB beans, and tables
  Data beans are grouped into several component groups.
- Cross-reference of commands, tasks, and tables
  URL commands, controller commands, task commands, view commands and tables are related to each other.
- Cross reference: Commands to beans to database tables
  Use this information when you are customizing a command and you want to know which tables are affected. You should also use this topic if you are modifying a table and want to know which commands and beans are affected.
- API changes between WebSphere Commerce Version 7.0.0.9 and WebSphere Commerce Version 8.0.0.0
  If you are migrating version 7.0 of WebSphere Commerce, review the API changes between releases.
- WebSphere Commerce database schema
  The WebSphere Commerce database model was designed for data integrity and optimal performance. WebSphere Commerce provides several hundred tables that store WebSphere Commerce instance data. To maintain data integrity, and to ease maintenance referential integrity, constraints are widely used in the database model. Indexes are used carefully on tables to avoid over-indexing and to provide a good balance between data retrieval and data manipulation activities (insert and update). The business rules are implemented at the application level rather than by using database trigger. Triggers, however, are used to facilitate data staging and optimistic locking. A limited number of SQL-based database stored procedures are used for data intensive activities.
- Payments subsystem
  In WebSphere Commerce, payment processing uses the Payments subsystem.
- Dynamic caching
  In general, caching improves response time and reduces system load. Caching techniques are used to improve the performance of World Wide Web Internet applications. Most techniques cache static content (content that rarely changes) such as graphic and text files. However, many websites serve dynamic content, containing personalized information or data that changes more frequently. Caching dynamic content requires more sophisticated caching techniques, such as those provided by the WebSphere Application Server dynamic cache, a built-in service for caching and serving dynamic content.
- Data Load utility configuration file schema
  The Data Load utility contains several configuration files. You can use the configuration file schema to understand and customize the data load configuration files.
- WebSphere Commerce web services
  WebSphere Commerce provides many web services.
- Utilities
  Utilities help you to accomplish administrative or configuration tasks, for example, loading data, publishing a store.
- Shopping flow URLs
  WebSphere Commerce shopping flow URLs are organized by subsystem.
  - Catalog subsystem URLs
    Catalog subsystem URLs include all logic and data relevant to a catalog, including categories, products and their attributes, items, and groupings of each, and any associations or relationships among them.
  - Member subsystem URLs
    The Member subsystem includes all logic and data relevant to registration, authentication, and grouping of all members. A member can be a user, an organization or organizational entity, or a member group.
  - Messaging system URLs
    The following URLs relate to the Messaging system.
  - Order Management subsystem URLs
    The Order Management subsystem includes all logic and data relevant to placing, processing, and managing orders. The Order Management subsystem also deals with returns.
  - Scheduler URLs
    The server subsystem consists of functions that are associated with URLs that are run by the scheduler.
    - ActivityCleanUp
      This is a scheduler command that is used for cleaning up the activities data that are stored in the CTXMGMT and CTXDATA tables.
    - AddJob
      This URL schedules a job on behalf of a site or store.
    - AddBroadcastJob
      This URL schedules a broadcast job for the WebSphere Commerce scheduler.
    - CleanJob
      This command removes job status records from the WebSphere Commerce scheduler status table.
    - DynaCacheInvalidation
      The DynaCacheInvalidation command is a scheduled command that can be invoked on a URL to invalidate entries in the WebSphere Application Server dynamic cache.
    - EditJob
      This command modifies an existing job currently being run by the scheduler.
    - RaiseECEvent
      Invoked by the WebSphere Commerce scheduler to process pending base ECEvents. This URL is called by scheduler. No display page will return.
    - RefreshRegistry
      Refreshes the registry information about all clones, as a background job.
    - RemoveJob
      This command cancels a job scheduled to run by the scheduler.
    - ScheduledDataDeploy
      The command is used to deploy the data contained in a SAR to the commerce EAR.
    - SchedCoupon
      Invoked by the WebSphere Commerce scheduler to process current coupons to check for expiration. This URL is called by scheduler. No display page will return.
    - TicklerUnlockMonitor
      Unlocks ticklers locked for more than a specified period of time. This is invoked by a scheduled job.
  - WebSphere Commerce Search URLs
    The starter stores consist of pages that are associated with URLs that are run by WebSphere Commerce Search. You can use the following URLs to invoke various WebSphere Commerce search tasks.
- Ant targets
  A WebSphere Commerce instance can be created from the command line. The command-line utility uses Apache Ant to create the objects required. The targets are divided into several high-level groups that correspond to the environment that is to be configured.
- Glossary

AddBroadcastJob URL

This URL schedules a broadcast job for the WebSphere Commerce scheduler.

URL structure

http:// host_name/path/: The fully qualified name of your WebSphere Commerce Server and the configuration path

Parameter values

http:// host_name/path/

The fully qualified name of your WebSphere Commerce Server and the configuration path

langId

Sets or resets the preferred language for the duration of the session; the supported languages for a store are found in the STORELANG table

storeId

The reference number of the store associated with this command

URL

Required: The URL to be called when the command completes successfully

name

The user on whose behalf the scheduler runs the job. This parameter is pulled from the LOGONID column in the USERREG> table

pathInfo

Required: The WebSphere Commerce command the executes for this job. In the following example, the pathInfo is "CleanJob":


request=wcs/servlet/CleanJob?endTime=0100

queryString

The parameters of the command to run. In the following example, the queryString is "endTime=0100": request=wcs/servlet/CleanJob?endTime=0100 All special characters, such as =, &, /, and ?, must be encoded.

Example 1

This example adds a broadcast job:


http://myhostname/webapp/wcs/stores/servlet/AddBroadcastJob?pathInfo='/
InterestItemDisplay'&URL=basemall.jsp&name=login999

Example 2

The following example schedules a job which will run the RefreshRegistry command, providing it with the parameter &registryName=top. It will run on behalf of the user wcsadmin, starting immediately:


   
http://myhostname/webapp/wcs/stores/servlet/AddBroadcastJob?name=wcsadmin
   
&pathInfo=RefreshRegistry&queryString=registryName%3DStoreRegistry%26URL%3D%2F&URL=/

Behavior

Sets a broadcast job for the background server to run. The broadcast applies to all clones (all Java Virtual Machines).
Adds an entry to the SCHCONFIG and the SCHACTIVE tables.
It only run once on each JVM. No attempts and delay parameters needed, as they are always set to the default to 0, 0.

Exception Conditions

None.