ShowAndPublish Verb BOD

For business objects of type ‘BOD’ having the PublishEvent method implemented, the following methods are also available:

ShowAndPublishSyncBOD, ShowAndPublishProcessBOD, ShowAndPublishLoadBOD, ShowAndPublishPostBOD, ShowAndPublishUpdateBOD.

However, these functions will only be available for the events that are marked as ‘can be published’ in the BID.

The interface is as follows:

long ppmmm.bl999st00.OrderBOD.ShowAndPublish<Verb>BOD(
	domain  		ppmmm.orno		i.internalOrderNumber,  | for example
	const			 	string			   i.actionCode,
	const				 string			   i.documentId,
	const			 	string			   i.revisionId,
	const				 string			   i.variationId,
	const	 			string			   i.tenantId,
	const		 		string			   i.accountingEntityId,
	const			 	string			   i.locationId)

The behavior of the ShowAndPublish<Verb>BOD method is comparable to the ShowAndPublishEvent (see ShowAndPublishEvent), except that additional details as needed for BODs can be set, the error handling differs, and the ShowAndPublish<Verb>BOD methods are unavailable for subcomponents.

The methods must be called from within a database transaction.

The objects are published as they are at the moment of publishing. So if an object is changed and that event must be published, the publishing method must be invoked after the actual change (but before the commit of the transaction). For example, the after.save hook of a DAL or the after.after.save hook of a user exit script can be used.

Input:

The parameter shown above as i.internalOrderNumber will be different per business object and per component. Also the number of parameters will differ. See the specifications for ShowAndPublishEvent in ShowAndPublishEvent.
i.actionCode. When publishing a Process, Sync, Load, Post or Update request, the developer can set an ‘actionCode’ controlling attribute. The actionCode is used to set the actionCode XML attribute of ActionCriteria.ActionExpression in the verb part of the BOD. The actionCode values that can be used are “Add”, “Replace”, “Change”, “Delete”, or an empty string. If empty, no actionCode attribute will be included in the BOD, and also its empty parent nodes ActionExpression and ActionCriteria will be omitted.
If i.actionCode is “Delete”, the Show method is not invoked for the object instance. In that case only the identifiers of the top-level component are included in the message to be sent. This is comparable to the ShowAndPublishStandardEvent for event action ‘delete’, see ShowAndPublishStandardEvent.

Refer to BOD Message Contentson how the action code is included in the BOD application area.
i.documentId. Part of the BODID (see specifications below). This element must be filled.
i.revisionId. Part of the BODID (see specifications below).
i.variationId. Part of the BODID (see specifications below).
i.tenantId. Part of the BODID (see specifications below). This element must be filled.
i.accountingEntityId. Part of the BODID (see specifications below).
i.locationId. Part of the BODID (see specifications below).

The BOD that is published will contain a BODID (refer to BOD Message Contents on the location of the BODID in the BOD application area). The BODID will have the following format:

infor-nid:<tenantId>:<accountingEntityId>:<locationId>:<documentId>:<revisionId>?<Noun>&verb=<Verb>&variationID=<variationId>

For example, if:

ShowAndPublishSyncBOD is used for the SalesOrderBOD
i.documentId = “ 12345”
i.revisionId = “”
i.variationId = “24 ”
i.tenantId =- “default”
i.accountingEntityId = “entity”
i.locationId = “ ”

then the BODID will be:

infor-nid:default:entity: :
		12345:?SalesOrder&verb=Sync&variationID=24

The variationID name-value pair will only be available if i.variationId is filled (not isspace).

Note that leading and trailing spaces are not removed.

Each of the IDs must be of the normalizedString type (see http://www.w3.org/TR/xmlschema-2/#normalizedString). A normalizedString must not contain carriage return (#xD), line feed (#xA) or tab (#x9) characters. The contents of the IDs are not checked inside the ShowAndPublish<Verb>BOD, except for an 'isspace' check on mandatory IDs.

It is advised to avoid colons (‘:’) in document id, revision id variation id, tenant id, accounting entity id, and location id. If you include colons, the application receiving the event may have problems interpreting the BODID.

Output:

Return value: 0 if successful, <> 0 if an error occurred. All errors that occur until the message is stored safely in the outgoing queue (actually a table) are reported back to the calling application.
If the return value <> 0 then one or more DAL error messages are set. If return value = 0 then one or more DAL warning messages may be set. The DAL messages will at least include the business object name or noun and verb. The messages do not have to include all details. Detailed information may be logged in $BSE/log. In that case the message will contain a reference to the details consisting of log file name (including path) and a timestamp that is included in the log file

The component ID cannot be specified in ShowAndPublish<Verb>BOD. The component ID will always contain “erp”.

When specifying incorrect input the following happens:


i.actionCode not in { “Add”, “Replace”, “Change”, “Delete”, empty string }	Return value <> 0. Note: action codes “Accepted”, “Modified” or “Rejected” cannot be used in ShowAndPublish<Verb>BOD.
i.documentId is empty or contains spaces only	Return value <> 0.
Incorrect i.documentId, i.revisionId, i.variationId, i.tenandId, i.accountingEntityId, or i.locationId	This is not detected; the technology cannot validate whether the application specifies the correct values. Also no check is done on whether these parameters contain valid characters only. If one or more incorrect values are specified then ION or the receiving application may run into an error.

Other exceptions are handled in the same way as in ShowAndPublishEvent, see ShowAndPublishEvent.

Note:

The exception handling differs significantly from ShowAndPublishEvent as used for BDE events.
The exceptions that result in a return value <> 0 may also do so if no ‘subscription’ exists for the corresponding noun and verb.

The following example shows how a ShowAndPublishSyncBOD method can be used to publish events occurring in LN. The last column shows how the receiving application can act when receiving the event.


Event occurring in LN	Event Publishing	Event Processing in OnSync
Create an order	ShowAndPublishSyncBOD on header, action code ‘Add’	Use the standard Create method
Change an order header	ShowAndPublishSyncBOD on header, action code ‘Change’	Use the standard Change method
Delete an order	ShowAndPublishSyncBOD on header, action code ‘Delete’	Use the standard Delete method
Create an order line	ShowAndPublishSyncBOD on header, action code ‘Delete	Use the standard Change method after setting action type ‘createOrChange’ for all components
Create an order line	ShowAndPublishSyncBOD on header, action code ‘Replace’	Delta detection (see below)
Change an order line	same as Create an order line	same as Create an order line
Delete an order line	ShowAndPublishSyncBOD on header, action code ‘Replace’	Delta detection (see below)

Note: Unfortunately, in a BOD you cannot set action types at component level. Only an action code at message level is available. Because of this a rather complex delta detection process is needed. The main problem is that for a ‘Replace’, deleted subcomponent instances (such as order lines) are not listed explicitly in the BOD. So the receiving application must compare the incoming BOD to its own persistent data. Additionally, quite some overhead exists for unchanged component instances, because either the receiving application must check whether anything has changed, or the receiving application must simply change the existing data in the database.

For example:


Database status when receiving the BOD	Incoming Sync BOD having action code ‘Replace’	Required actions to synchronize
Order X, Order line 1, Order line 2	Order X, Order line 2, Order line 3	Change Order X, Delete Order line 1, Change Order line 2, Create Order line 3

Alternatively, you can simply delete the existing order and create the new one based on the incoming BOD. However, in many cases that won’t work in practice, because deletion cannot be done if references to the order exist.