====== Posting of article data using Jobsteps TradeItemManagerFillCache, TradeItemManagerBookCache ======

=== Direct posting of article data from a merchandise management system or from an ERP system ===

== Soft migration of the old update job (use only after consultation with Pranke GmbH) ==

By exchanging the step TradeItemManagerDirectSql with the TradeItemManagerFillCache and TradeItemManagerBookCache (as shown in Figures 1 and 2) the data can be directly updated in the **ArticlePool_ArticleCache** table.\\ 
**Attention:** It can cause problems if an error occurs when the data is updated by the TradeItemManagerBookCache job step and a ReRun is then executed in the job. If an error occurs during update, the corresponding cache table is not emptied by the selected stored procedure. In this case, the data of the processed document cannot be inserted into the cache table again without causing a primary key violation. In order to avoid this case, the concept for such a job set-up should be discussed with Pranke GmbH before commissioning. \\ 
**Figure 1**{{images:book_article_in_articlepool2.jpg?565x180}} **Figure 2**\\ \\ {{images:book_article_in_articlepool3.jpg?889x150}}\\ 
The whole job now looks like this: **Figure 3**\\ 
{{images:book_articles_in_articlepool4.jpg?1423x670}}\\ 
The job in the yellow circle in Figure 3 is triggered by the external job containing the **Delegator to ArticlePoolFillCache**. The external job picks up the messages. \\ 
As soon as all article data is in the **ArticlePool_ArticleCache table**, which has been done by delegating to the ArticlePool job shown in Figure 3 in the yellow circle, the update of the articles starts by the two steps below the Delegator of the external job. \\ 
{{:images:sign_warning.png?nolink|}}**Note:** The first step is a **//TradeItemManagerFillCache//**, which executes a StoredProcedure "//**ArticlePool_ClearCache**//" to delete its contents as soon as the job is started. This ensures that no error is caused by duplicate entries in the cache if an exception occurs during the update of articles in the article pool.
Since the **// update steps relevant to the job are protected by a //**Lock mechanism**//, these jobs can only run **//// once at the specified time//**.