Exit Points are triggers that activate an Event (and in turn a Business Process) to email user(s) when processing errors or successes occur. An Exit Point sets a Server-wide notification Event (as opposed to setting up multiple objects in multiple Projects to handle notifications).
Cleo recommends using Exit Points to receive notification when a non-fatal error that you should address occurs. This will cut down on time spent in the Auditor view.
- Inbound Acknowledgment Error - Raises an Event when an inbound acknowledgement is received and not accepted or accepted with errors. If enabled, this Exit Point will raise an Event for each inbound 997 that reports an error. Launches at the message or document level. For a list of codes, see Acknowledgement Error Codes
- Inbound Duplicate Interchange - Raises an Event when the Studio identifies a duplicate interchange. This only works when the Process Duplicate Interchanges check box in the Inbound EDI Route editor is not selected.
- Inbound EDI Route Error Handler - Raises an Event when an Inbound EDI Route used during processing contains an error. Launches at the Interchange level.
- Inbound EDI Route Not Found - Raises an Event when an Inbound EDI Route can't be found during processing. (For example, if CIC encounters a Sender ID with no associated route.) Launches at the Interchange level.
- Inbound EDI Route Process Binding Not Found - Raises an Event when CIC finds a route, but does not find the corresponding process binding (to the Business Process used for the message/interchange). Process Binding is set in the Inbound EDI Route editor. Launches at the Interchange level.
- Inbound Interchange Processed - Raises an Event every time CIC identifies and analyses an EDI interchange. Processed does not mean "processed without errors" - you can still get other Exit Point notifications after receiving an Inbound Interchange Processed notification.
Note: By default, this Exit Point generates an e-mail for each interchange processed. Users should consider the volume of emails they will receive before using this Exit Point, especially when experiencing high-volume EDI activity. Cleo recommends placing logic in the copied Business Process to narrow the number of interchanges processed when using Inbound Interchange Processed.
Exit Points are not objects but do rely on two objects: Events and Business Processes.
Events are enabled in the Admin Console | Settings view. A server must be running.
Cleo supplies example Business Processes named after each Exit Point in the com.cleo.CIC.shippedObjects Project, available through your Cleo Repository. If you have not already accessed it, see Connecting to the Cleo Repository.
Any Exit Point Business Processes you want to use should be copied to your CORE Project - preferably to a package with exitPoints in its name - and can be modified to your company's specifications. Then create an Event to call that Business Process, and associate that Event with the corresponding Exit Point. When the defined error or success occurs, the Exit Point triggers the Event, which sends relevant information to a Business Process. That Business Process then attaches the information to an email and sends it to users.
Each Events contain parameters for the data that is specific to the purpose of the Exit Point scenario. For a list of them, see Exit Point Business Process Parameters.
Non-fatal errors (those that do not stop processing) display differently in the Admin Console | Auditor than fatal errors (those that make processing impossible). While it's easy to identify a fatal error, non-fatal errors can be more time-consuming to locate and, depending on your business' needs, you may not even want to be made aware of all non-fatal errors. Using Exit Points makes the non-fatal errors that matter to you obvious, helps you decide whether you need to address the errors, and saves you the time you'd otherwise spend looking through the auditor.
You can also use the Inbound Interchange Processed Exit Point. Suppose you want to generate an e-mail once a specific message type from a specific trading partner finishes processing. The message is inbound EDI with 1 ISA and 100 messages within. Your normal inbound EDI process runs per message. You, however, only want a single e-mail. Also, you’re only concerned with this specific trading partner, and not every EDI message received.
You can set up the Interchange Processed Exit Point to send an e-mail when this message finishes processing. In addition to the e-mail, you could also edit the Business Process to write the inbound EDI to a flat file for each message, and then trigger an external program to perform another action. You can also pass interchange data (from the transformation, collaboration, or event parameter) into the task being executed when the file finishes processing.
How Exit Points Work
While you can create a Business Process to handle errors however you want to handle errors, under normal circumstances you would have to associate that Business Process with each Project. Exit Points allow CIC to apply notifications Server-wide.
An Exit Point uses an Event to associate a specific error with a specific Business Process, triggering that Business Process every time that error is encountered regardless of which Project its associated with.
- Decide which Exit Points you want to use.
- For each Exit Point, copy the corresponding Business Process from the Cleo repository and edit it to your specifications.
- For each copied Business Process, create an Event and associate the copied Business Process with it.
- In the Admin Console's Settings tab, associate the Event with its corresponding Exit Point.
- Leave Exit Points you do not want to use unassociated.