...
Communication | |||||||
---|---|---|---|---|---|---|---|
Stop communication from SAP to FSM | Stop channel communication. Activating this field will stop channel processing with message ‘The Channel is not active - raising the error’ (idocs will not be transferred to SAP FSM). | ||||||
Bulk processing | When the ‘Bulk processing’ option is enabled, objects sent to FSM are removed from the SAP standard queue (processed from a system perspective) and placed into an internal, dedicated Connector’s queue. If the number of objects reaches the predefined limit or there are no more relevant objects in the standard queue to select, the Connector combines all the objects and sends them to the message broker in a single call. This optimization ensures that the related web service is invoked once instead of being called individually for each message. The maximum number of messages that can be sent together is controlled by the parameter ‘Transactions per LUW.’ Enabling this flag can improve message sending time in highly loaded systems, but it must be used cautiously. The solution relies heavily on data selection from the ARFCSDATA table, so it’s possible that obtaining data from this table may take longer than the system saves by limiting the number of web service calls. | ||||||
Activate low-prio queue | If the standard queue is in processing (queue has no stop entry) the system checks the amount of entries in the queue. If the amount is equal or bigger than the ‘Stop low at’ value, the low priority queue should be stopped (only if the queue is not already stopped). If the amount of entries is equal or smaller than the ‘Rel. low at’ value, the low priority queue will be released (only if the queue is stopped). If one of the values is empty the new functionality is deactivated. The second value needs to be smaller than the first oneThe FSM Connector can place selected objects (based on Low priority queue setting in /PACG/ECM_CLSASSIG) into a so-called low-priority queue. Since there is no inherent prioritization of queues, this is achieved by dynamically pausing and starting the low-priority queue based on the number of elements in the standard queue. Two parameters control this behaviour: ‘Activate low-prio queue’ and ‘Stop low-prio queue.’ Specifically, if the number of objects in the standard queue drops below the specified ‘Activate low-prio queue’ threshold, the low-priority queue is activated. Conversely, if the number of elements in the standard queue reaches the ‘Stop low-prio queue’ threshold, the low-priority queue is paused ‘Stop low-prio queue' parameter must be higher than ‘Activate low-prio queue’.
| ||||||
Stop low-prio queue | Upper threshold at which low-prio queue is paused. | ||||||
Select type of queue of outgoing conf. | Specify which queue will be used for processing of outbound confirmations. The options include:
| ||||||
| When enabled, the Connector can utilize a so-called express queue. This queue operates as follows: when an object is added to it, all other Connector-related queues are paused to make room for processing. Once the express queue is emptied, the FSM Connector resumes previously blocked queues. Objects can be added to the express queue using the BAdI /PACG/ECM_IDOC_EXP_QUEUE. The BAdI features only one method, SET_EXP_QUEUE, which determines whether a message should be added to the express queue based on received data. | ||||||
Use inbound queue | If checked, inbound idocs will be created and processed using the inbound queue (SMQ2), instead of the outbound queue (SMQ1). Inbound confirmations will also be processed using the inbound queue.
BAdI for parallelization of inbound processing Implement BAdI /PACG/ECM_IN_QUEUE to create more than one queue for inbound idoc processing. The BAdI can change queue name based on company ID and idoc content. | ||||||
Type of queue for incoming messages | Specify which queue will be used for processing of inbound messages. Inbound messages used to be processed by queue /PACG/ECM_STD_IN. The current options include:
| ||||||
Type of queue of incoming confirmations | Specify which queue will be used for processing of inbound confirmations. Technical note Such confirmations are generated after transferring an object to SAP FSM and are handled by function /PACG/ECM_X_IDOCCONF. They are necessary for an outbound idoc to be set to status 41. Inbound confirmations used to be processed by queue /PACG/ECM_STD_IN. The current options include:
This additional field is ‘bgRFC destination name’ as defined with SBGRFCCONF transaction. ‘bgRFC destination‘ is a mandatory parameter required for processing to start. | ||||||
Selected bgRCF destination | If either for ‘incoming confirmation’ or ‘incoming messages’ the ‘bgRFC processing’ is selected also bgRFC destination must be selected. The bgRFC can be defined using 'SBGRFCCONF' transaction. | ||||||
| During inbound processing, FM /PACG/ECM_S_INPUT responsible for initial FSM message handling, is called by default without destination specified. This means that tRFC with destination NONE is used, which can cause performance issues (destination NONE can be used by various other processes, it can cause delay of even 15 minutes and cause transporter to resend a message to SAP). To limit negative impact on inbound processing performance, enter in the hereby described field the name of an internal or logical RFC Connection (Destination) dedicated to FSM Cloud Connector processes. The RFC Connection should be created and adjusted performance-wise beforehand in transaction SM59.
| ||||||
| During inbound processing, web service function module /PACG/ECM_S_INPUT is called by default in background task. This is because FSM Cloud Connector tries to minimize the synchronous part of the call. On certain landscapes synchronous processing of IDocs however may prove to be more efficient. Enable this field to activate synchronous processing of inbound messages.
On a reference system, synchronous idoc processing allowed for processing of ca. 4 messages/second. | ||||||
| Enable use of the failover mechanism with the message broker |
...