|
Oracle Workflow Developer's Guide Release 2.6.3.5 Part Number B12161-02 |
|
|
|
|
|
||
| Previous | Next | Contents | Index | Glossary |
Two item types are delivered with the XML Gateway: the XML Gateway Standard Item Type and the XML Gateway Error Processing Item Type.
XML Gateway Standard Item Type - The XML Gateway Standard Item Type includes the Raise Document Delivery Event, which is used to raise a business event from an existing Workflow process. This allows you to seamlessly integrate your existing Workflow process with Oracle XML Gateway to create an outbound XML message. The functions included with the XML Gateway Standard Item Type are Consume XML Document, Generate XML Document, Generate Trading Partner XML Document, Send Document, Transform XML, and Transaction Delivery Required.
Configure the seeded events and event subscriptions delivered by the Oracle E-Business Suite for pre-built XML messages in support of Business-to-Business or Application-to-Application integration.
XML Gateway Error Processing Item Type - The XML Gateway Error Processing Item Type contains error handling processes to manage errors detected by the Oracle Workflow Business Event System or Oracle XML Gateway. The error processes are: Default Error Process, ECX Engine Notification Process, ECX Main Error Process, ECX Main Inbound Error Process, ECX Main Outbound Error Process, Error Handling for Inbound Messages, and Error Handling for Outbound Messages.
The XML Gateway Error Processing Item Type supports two event activities: Receive Error and Receive Send Notification Event. The Receive Error event is used by the XML Gateway to indicate that the XML Gateway execution engine has detected an error. The Receive Send Notification Event is used to indicate that the execution engine has identified a need to send a notification for errors related to an inbound process.
Oracle Workflow error handling provides active error notification to the XML Gateway System Administrator or Trading Partner with support for the Workflow retry and reprocess features. The functions provided by the XML Gateway Error Processing Item Type are: ECX Reprocess Inbound, ECX Resend Outbound Message, Get ECX In Error Details, Get ECX Out Error Details, Get System Administrator Role, and Get Trading Partner Role.
For more information, see: Oracle XML Gateway User's Guide.
Calendar, leveraging the Oracle Workflow Business Event System, publishes business events for appointments when the following conditions occur from APIs or application user interfaces (UIs) in HTML or the Oracle Applications Framework-based modules:
For example, if an appointment is created with invitees, this action is published or "raised" as a business event. This event can be, for example, captured to send relevant workflow notifications. If an appointment is created, updated, or deleted, this action is raised as a business event. This event can trigger a synchronization between Oracle Applications and the offline device, such as a Palm or Outlook.
Calendar publishes the following business events for appointments:
Task Manager, leveraging the Oracle Workflow Business Event System, publishes business events when a task or an assignment is created, updated, and deleted from APIs or from the Forms, HTML, or Oracle Applications Framework-based application user interfaces (UIs). Applications that contain data directly affected by these events can subscribe to them and synchronize or modify their data accordingly.
Task Manager publishes the following business events:
Asset Retirement Event - This business event is raised when you retire assets in the Oracle Assets system.
Asset Transfer Event - This business event is raised when you transfer assets within the Oracle Assets system.
Invoice Inbound - This business event is raised when Payables receives an XML invoice from a supplier's accounts receivable system.
Payment Format - This business event is raised when a payment batch or Quick payment is formatted. One example of its use is that it initiates the Transmit Payment File Program of the Automatic Bank Transmission feature.
Payment - This business event is raised when a payment batch is confirmed or a Quick payment is created. One example of its use is that it initiates the E-mail Remittance Advice Program.
Send XML Payment - This business event is raised when a user formats a payment or a payment batch that uses the OAG XML payment program. This event starts the Process Payment Message workflow, which sends an XML Payment message to your FSP (bank).
XML Payment Confirmation - This business event is raised when the FSP (bank) sends a Confirm BOD XML message to the ERP. This event continues and completes the Process Payment Message workflow.
XML Payment Errors - This business event is raised when the FSP (bank) sends a Payment Errors XML message to the ERP. This event starts the Process Payment Errors Message workflow.
XML Payment Advice - This business event is raised when the FSP (bank) sends a Payment Advice XML message to the ERP. This event starts the Process Payment Advice Message workflow.
Admission Application Creation - This event is triggered when an application is created. It can be used to create a user-defined process to calculate residency status.
Admission Application Import - This event is triggered when an application is imported from an external source such as the common application. It can be used to create a user-defined process to calculate residency status.
Admission Application Import Outcome Decision - This event is triggered when an application's outcome decision is imported. It can be used to create a user-defined process to calculate residency status.
Admission Outcome Status Update - This event is triggered when an application outcome status is updated. It can be used to create a user-defined process to calculate residency status. It includes parameters to be used for workflow notifications.
Admission Self Service Application Creation - This event is triggered when an application is submitted through self-service. It can be used to create a user-defined process to calculate residency status.
Appeal Upheld / Dismissed - This event is triggered when the appeal decision is upheld or denied.
Apply Negative Outcome - This event is triggered when a negative outcome is applied against a student.
Apply Positive Outcome - This event is triggered when a positive outcome is applied against a student.
Approve Outcome - This event is triggered when a positive outcome is approved.
Attendance Advance Notice - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to send advance notification to an instructor informing him or her about attendance submission dates.
Attendance End - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the attendance submission period has ended.
Attendance Start - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the attendance submission period has started.
Cohort Status Change - This event is triggered by a class rank status change. The event contains the cohort name, cohort instance, new cohort status, and new rank status.
Confirmation of Registration - This event is triggered when a research candidacy is confirmed. A research candidacy can be confirmed when pre-enrollment is triggered from admission on acceptance of an offer. The candidacy may also be manually confirmed in the Program Attempt window.
Early Final Advance Notice - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to send advance notification to an instructor informing him or her about the early final grading period grade submission dates.
Early Final End Date - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the early final grading period grade submission period has ended.
Early Final Start - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the early final grading period grade submission period has started.
Final Advance Notice - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to send advance notification to an instructor informing him or her about final grading.
Final End Date - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the final grading period grade submission period has ended.
Final Start - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the final grading period grade submission period has started.
Generate User Name - This event is triggered when a user attempts the new user registration process in self service. It can be used in conjunction with the Generate User Name workflow to create a user name for a person to log in through self service.
Grade Mid Term - This event is triggered from the Review Grade self service screen for the mid term grading period. It can be used to create a user-defined process to see the resolution of grade submission for the mid term grading period from the lead instructor of a unit section.
IGSSWTST/Main_Process - There are two events for this item type. One event is triggered when users change values of Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday, Start_Time, End_Time, Building_Code, Room_Code, or Instructor_Id in the Unit Section Occurrences window. The workflow for this business event can be set up to notify users when a unit section occurrence is changed. The other event for this item type is triggered when users change the status of a unit section to Cancel in the Unit Section Details window. This event makes necessary changes in scheduling. The workflow for this business event can be set up to notify users when a unit section is cancelled.
Incomplete Applications - This event is triggered for the applicant or applicants with incomplete self-service applications. A sample Incomplete Applications workflow is triggered by the new business event. You can update this sample workflow.
Incomplete Grade Default - This event is triggered from the Assign Incomplete Grade concurrent process. It can be used to create a user-defined process to notify an instructor about the finalization of the default incomplete grade to a certain student.
Incomplete Grade Submission - This event is triggered from the Enter Incomplete Grade self service screen. It can be used to create a user-defined process to notify an instructor about submitting an incomplete grade for a student.
Inform Instructor About Assessment Item Grades Release to Student - This event is triggered when assessment item grades are released to a student.
Inform Instructor That Unit Section Grades Have Been Submitted - This event is triggered when unit section grades are submitted for the midterm and final.
Key Program Change - This event is triggered when a key program change occurs.
Mid Term Advance Notice - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to send advance notification to an instructor informing him or her about the mid term grading period grade submission dates.
Mid Term End Date - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that mid term grading period grade submission period has ended.
Mid Term Start - This event is triggered from the Generate Assessments Notifications concurrent process. It can be used to create a user-defined process to notify an instructor that the mid term grading period grade submission period has started.
Milestone - This event is triggered when a milestone is created and saved against a candidacy, whether by defaulting all program milestones or by adding milestones on an ad hoc basis. The Milestone event is raised when there are changes to the Milestone Type, Due Date, Milestone Status and Date Reached. If a planned milestone is deleted, the event is raised as well.
Milestone Notification - This event is triggered when you indicate notification days. You can nominate three triggers for a notification: Imminent, Reminder, and Re-Reminder.
oracle.apps.igs.en.dropnotification - This event is triggered when the student's unit attempt status is changed to Dropped or Discontinued.
oracle.apps.igs.en.dropnotification - This event is triggered when the unit attempt status for enrolled units changes to Dropped or Discontinued for a discontinued program.
oracle.apps.igs.en.dropnotification - This event is triggered when the unit attempt status for enrolled units changes to Dropped or Discontinued for a transferred program.
oracle.apps.igs.en.dropnotification - This event is triggered when the unit attempt status for enrolled units changes to Dropped or Discontinued for an intermitted program.
oracle.apps.igs.en.enrp.instresp - This event is triggered when an instructor submits a response to an audit permission or special permission request. It can be used to create a user-defined process to notify students of the instructor's response to special permission requests.
oracle.apps.igs.en.enrp.statmail - This event is triggered by a change in unit attempt status. It can be used to create a user-defined process to notify users when there is a change in the unit attempt status.
oracle.apps.igs.en.enrp.studreq - This event is triggered when a student submits an audit permission or special permission request. It can be used to create a user-defined process to notify instructors of special permission requests.
oracle.apps.igs.en.inform_stud - This event is triggered when any program attempt information is changed. It can be used to create a user-defined process to notify users when any program attempt information is changed.
oracle.apps.igs.en.transfernotification - This event is triggered when a unit section is transferred.
oracle.apps.igs.en.wlst.mailadm - This event is triggered when a waitlisted student fails enrollment eligibility validations during auto-enrollment. It can be used to create a user-defined process to notify users of students who fail enrollment eligibility during the automatic enrollment process.
oracle.apps.igs.en.wlst.mailstud - This event is triggered when a waitlisted student passes enrollment eligibility validations during auto-enrollment. It can be used to create a user-defined process to notify users of students who pass enrollment eligibility during the automatic enrollment process.
oracle.apps.igs.en_be_en002 - This event is triggered when a student is retrieved by the Minimum Credit Point Query window and the administrator decides to notify the student.
oracle.apps.igs.pe.extholdfl - This event is triggered by Oracle Student System to inform the external system that an attempt to set or release an external hold has failed. The external system can catch this event and continue further processing.
oracle.apps.igs.pe.extholdss - This event is triggered by Oracle Student System to inform the external system that an attempt to set or release an external hold has been successful. The external system can catch this even and continue further processing.
Outcome Removed / Waived / Cancelled - This event is triggered when an outcome is removed, waived, or cancelled.
Outcome Status Change - This event is triggered when an outcome status is changed and saved.
Rank Override - This event is triggered by overriding a class rank. The event contains the student ID, student name, current rank, override rank, override comment, and person ID and name of the person who entered the override details.
Ranking Process Complete - This event is triggered by completion of the Run Ranking Process concurrent process. The event contains the cohort name, cohort instance, run date, and cohort total.
Saved Transcript - This event is triggered when a transcript is saved.
SEVIS Exchange Visitor Request Processed - This event is triggered when the concurrent process for an Exchange Visitor is submitted. This event processes SEVIS data.
SEVIS Non Immigrant Request Processed - This event is triggered when the concurrent process for a Non Immigrant is submitted. It processes SEVIS data.
Show Cause Upheld / Dismissed - This event is triggered when the show cause decision is upheld or denied.
Submit Exchange Visitor Batch Request - This event is triggered when the concurrent process for an Exchange Visitor is submitted. This event generates and sends the Exchange Visitor XML file.
Submit Non Immigrant Batch Request - This event is triggered when the concurrent process for a Non Immigrant is submitted. It generates and sends the Non Immigrant XML file.
Thesis Exam - This event is triggered when a thesis exam is submitted or on any further resubmission. You can notify the student, principal supervisor, and the Thesis Panel Member.
Thesis Result - This event is triggered when a thesis result is saved or updated. You can notify students of the outcome of an thesis exam, including referrals.
Transcript - This event is triggered when a transcript is entered for a person.
Operation Approval - The Change Status window in Product Development starts the signature capturing process whenever an operation status change is requested. When the status of an operation is changed, the E-Signatures can be captured at multiple points in the process. Required signatures are captured online, while the event is happening in the window. Any users responsible for additional required signatures receive workflow notifications informing them that their E-Signature must be entered before the status of the operation is changed to the requested status.
Routing Approval - When the status of a routing is changed, the E-Signatures can be captured at multiple points in the process. When the status change is requested, required signatures can be captured online, while the event is happening in the window. Any users responsible for additional required signatures receive workflow notifications informing them that their E-Signature must be entered before the status of the routing is changed to the requested status.
Formula Approval - When the status of a formula is changed, the E-Signatures can be captured at multiple points in the process. When the status change is requested, required signatures can be captured online, while the event is happening in the window. Any users responsible for additional required signatures receive workflow notifications informing them that their E-Signature must be entered before the status of the formula is changed to the requested status.
Recipe Approval - When the status of a recipe is changed, the E-Signatures can be captured at multiple points in the process. When the status change is requested, required signatures can be captured online, while the event is happening in the window. Any users responsible for additional required signatures receive workflow notifications informing them that their E-Signature must be entered before the status of the recipe is changed to the requested status.
Validity Rule Approval - When the status of a validity rule is changed, the E-Signatures can be captured at multiple points in the process. When the status change is requested, required signatures can be captured online, while the event is happening in the window. Any users responsible for additional required signatures receive workflow notifications informing them that their E-Signature must be entered before the status of the validity rule is changed to the requested status.
OPM Quality Management E-Signature Events
Specifications - After a specification is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the specification status changes to approved.
Customer Validity Rule Specifications - After a customer specification validity rule is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the customer specification validity rule status changes to approved.
Inventory Validity Rule Specifications - After an inventory specification validity rule is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the inventory specification validity rule status changes to approved.
Supplier Validity Rule Specifications - After a supplier specification validity rule is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the supplier specification validity rule status changes to approved.
WIP Validity Rule Specifications - After a WIP specification validity rule is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the WIP specification validity rule status changes to approved.
Monitoring Specification Validity Rule Approval - After a monitoring specification validity rule is entered and an Approved for Lab Use, or Approved for General Use status change request is made, the application generates an e-record that requires deferred e-signatures. When all e-signatures are acquired, then the monitoring specification validity rule status changes to approved.
Sample Creation - The Sample Creation e-signature is required when you create a new sample in Pending or Retained disposition. The e-record provides all information about sample identification, including its sample quantity, source, quality laboratory, sample dates, the specification attached to it, and any sampling plan information.
Result Entry - Upon saving results entered, an e-record is generated and online e-signatures are required before the results can be committed to the database. You do not have to enter results for all listed tests in order for the e-signature event to be raised. If more results are entered in subsequent sessions, then an e-signature is required at that time.
Mass Results Entry - Upon saving results entered in the Mass Results Entry window, an e-record is generated and online e-signatures are required before the results can be committed to the database. Results for all listed tests do not have to be entered in order for the e-signature event to be raised. If more results are entered in subsequent sessions, then an e-signature is required at that time. The Mass Results Entry event automatically raises the Result Entry event, creating an e-record for every sample results set. The individual Result Entry e-record is accessible from the Results window for a single sample.
Result Evaluation - Upon completing the process of saving a result set, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled at that time, then the results cannot be committed to the database. Results for all listed tests do not have to be entered in order for the e-signature event to be raised. If one or more test results are entered and saved, then an e-signature is required. If more results are entered in subsequent sessions, then an e-signature is required at that time.
Sample Disposition - The sample disposition event represents the review of an individual sample and assignment of a disposition. Upon changing the sample disposition, the sample disposition e-record is generated, and an appropriate e-signature event is raised. Signoffs take place online.
Sample Event Disposition - The sample event disposition event represents the review of samples within a sample group and the assignment of a sample group disposition. Upon changing the sample group disposition, an e-record is generated, and an appropriate e-signature event is raised. Signoffs take place online.
Sample Event Disposition Composite - The composite sample disposition event represents the review of composite results of samples within a sample group and the assignment of a sample group disposition. Upon changing the sample group disposition, an e-record is generated and e-signatures are required online.
Stability Studies Change Status - After a stability study is entered and a status change request is made, the application generates an e-record that requires online e-signatures. When all e-signatures are acquired, then the stability study status changes.
OPM Process Execution E-Signature Events
Release Batch - Release Batch is an event that signals that a batch has begun production, and that the automatic release ingredients have been consumed. The batch has an actual start date and the automatic release ingredients have actual quantities (if allocation was successful), supported by completed transactions.
Close Batch - Close Batch is an event that signals that a batch is completed and no further changes are made to the batch data. Close Batch assigns a date to the actual close date and changes the status of the batch to closed. Once the batch is closed, you can no longer make any adjustments, insertions, or deletions to the batch.
Release Step - When you release a step, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not released.
Close Step - When you close a step, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not closed.
Complete Batch - When you complete a batch, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the batch is not completed.
Complete Step - When you complete a step, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not completed.
Unrelease Batch - When you unrelease a batch, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the batch is not unreleased.
Unrelease Step - When you unrelease a step, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not unreleased.
Revert Batch to WIP - When you revert a batch to WIP, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the batch is not reverted to WIP.
Revert Step to WIP - When you revert a step to WIP, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not reverted to WIP.
Reopen Batch - When you reopen a batch, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the batch is not reopened.
Reopen Step - When you reopen a step, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the step is not reopened.
Insert, Update, or Delete Allocation or Edit Quantity - When an allocation is inserted, updated, or deleted, or a quantity is edited, an appropriate e-signature event is raised and the signoffs take place online. If all the necessary signatures cannot be fulfilled, then the allocation is not inserted, updated, or deleted, or the edited quantity is not saved.
OPM Inventory E-Signature Events
Lot Status Events - Approval of an OPM Lot Master and update of a Lot Master are performed online. When you are creating or updating a lot or sublot using the Lot Master window, the E-Signature event is raised when you save the data. This displays the E-Signature window. The new or updated data is not committed to the database unless all of the required signatures are obtained online, while the E-Signature window is open.
Quantities Events - Process Inventory transactions are configurable to capture E-Signatures and E-Records upon any of the following Inventory Quanitities transactions: Adjust Immediate, Create Immediate, Grade Immediate, Status Immediate, and Move Immediate transactions.
Item Events - When an existing item is modified, any E-Signatures required are captured online so that transactions requiring use of the item can function without interruption.
Item Create E-Record - When a new item is created, e-records and e-signatures may be required before activating the item. This process is initiated from Approve Item through the OPM Item Master window.
Item Update E-Record - When an existing item is updated, the e-signature event is raised upon save. The E-Signature window displays. The new or updated data is not committed to the database unless all of the required signatures are obtained while the window displays.
Item/Lot Unit Of Measure Conversion Entry - Approval of OPM item and lot unit of measure conversions is performed online. Upon save when creating or updating an item or lot UOM conversion through the Item Lot/Sublot Conversions window, the e-signature event is raised. The E-Signature window displays. The new or updated data is not committed to the database unless all of the required signatures are obtained while the window displays.
Mass Transaction Events - Process Inventory transactions can capture e-signatures and e-records upon the following mass inventory quantity transactions: Mass Grade Immediate, Mass Status Immediate, and Mass Move Immediate transactions. The new or updated data is not committed to the database unless all of the required signatures are obtained while the E-Signature window displays.
Acknowledgment - After order import has been run on data received through XML, a business event (oracle.apps.ont.oi.po_ack.create) can be raised to trigger generation of an ACKNOWLEDGE PO XML message. This message informs the buyer of the result of order import.
Show/Change Sales Order - A business event (oracle.apps.ont.oi.show_so.create) can be raised to trigger generation of a SHOW SO or CHANGE SO XML message. The value of one of the event parameters determines which of the two messages will be generated. The SHOW SO message contains status information about an order and can be generated on demand or as a result of changes to an existing sales order. The CHANGE SO message is used to notify the buyer of changes to a sales order and can be raised as a result of status or attribute changes on a sales order.
Confirm BOD - When an inbound XML document is received by Oracle Order Management, a business event (oracle.apps.ont.oi.cbod_out.confirm) can be raised to trigger the generation of a CONFIRM BOD XML message. This message informs the sender that their document was successfully received.
Integration Event - At various points in Oracle Order Management processing, generic business events (oracle.apps.ont.oi.xml_int.status) are raised with information pertaining to the transaction that is being executed. Internally, Oracle Order Management consumes these events for use in its Open Interface Tracking UI, but they are designed such that anyone interested in the information could subscribe to these events for their own use.
EDI Acknowledgment - A business event (oracle.apps.ont.oi.edi_ack_values.create) can be raised to trigger the derivation of acknowlegment data for use in outbound EDI messages (POAO and POCAO).
OMO Trigger Custom Action Event (oracle.apps.ams.trigger.TriggerCustomActionEvent) - This event gets raised whenever a Marketing trigger's condition has been met, or in the case of a date-based trigger, the time has been reached, and the necessary actions need to be performed. By subscribing to this event, customers can have their custom logic performed.
OMO Schedule Execution (oracle.apps.ams.campaign.ExecuteSchedule) - This event gets raised whenever a campaign schedule needs to be executed in Oracle Marketing. This could have happened through manual activation from screens, or through automated flows like Triggers or Repeating Schedules. This event will not get processed until the start date/time for the schedule is reached. Oracle Marketing provides two seeded subscriptions to the Schedule Execution Event. The first subscription starts the Schedule Execution workflow, which enables the execution of the schedule and all seeded activities that need to happen for it. The second subscription randomly marks one of the associated product categories as the primary category, and also stamps the live versions of the collaboration and media planner content items.
OMO Event for Repeating Schedules (oracle.apps.ams.campaign.RepeatScheduleEvent) - This event gets raised whenever a repeating campaign schedule is manually activated in Oracle Marketing. This signals the system to start the repetition flow for this campaign schedule. This event will also be raised whenever the schedule repetition workflow creates a new schedule instance. Oracle Marketing provides one seeded subscription for this event. This subscription starts the workflow process, which enables the repeating schedule functionality.
| Previous | Next | Contents | Index | Glossary |
