Vid Incremental.SalesOrdersV2Incremental uppstod felkod itgeneor328 upprepade gånger:
itgeneor328
Ett obligatoriskt filter saknas.
Kontakta Invantive Support.
Denna endpoint har obligatorisk filtrering tillämpad.
En GET-begäran för denna endpoint måste ha en $filter-parameter med ett av följande fält i url: Timestamp.
I andra rapporter finns också denna tabell; dessa uppdaterades tidigare i natt utan problem.
Sinds 6 augustus omstreeks 02:12 UTC treedt op veel Exact Online-omgevingen de volgende foutmelding op:
itgeneor328
Een verplicht filter ontbreekt.
The remote server returned an error:
(400) Bad Request.
Neem contact op met Invantive Support:
This endpoint has mandatory filtering applied.
A GET request for this endpoint must have a $filter parameter with one of the following fields in the url:Timestamp.
De foutmelding hangt niet samen met aanpassingen aan Invantive Cloud (uit stabiliteitsoverwegingen is er sprake van een zomerstop), maar waarschijnlijk een upgrade van Exact Online.
Het probleem lijkt alle Exact Online-omgevingen te raken, zowel on-premises als Invantive Cloud, Get My Report, Valuta Tools, App Online, Bridge Online als websites die zich baseren op Invantive-technologie en producten van partners.
Betrokken URLs, waarbij “123456” de divisiecode van een van uw Exact Online-administraties kan zijn:
https://start.exactonline.be/api/v1/123456/sync/CRM/Accounts?$orderby=Timestamp&$select=...https://start.exactonline.be/api/v1/123456/sync/financial/TransactionLines?$orderby=Timestamp&$select=...https://start.exactonline.be/api/v1/123456/sync/Financial/TransactionLines?$orderby=Timestamp&$select=...https://start.exactonline.be/api/v1/123456/sync/purchaseorder/PurchaseOrders?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/crm/Accounts?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/CRM/Accounts?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/CRM/Addresses?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Financial/GLAccounts?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Financial/GLClassifications?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/financial/TransactionLines?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Financial/TransactionLines?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/HRM/ScheduleEntries?$select=*https://start.exactonline.nl/api/v1/123456/sync/logistics/Items?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Logistics/Items?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Logistics/SupplierItem?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/project/TimeCostTransactions?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Project/TimeCostTransactions?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/PurchaseOrder/PurchaseOrders?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/salesinvoice/SalesInvoices?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/SalesOrder/GoodsDeliveryLines?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/salesorder/SalesOrderHeaders?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/SalesOrder/SalesOrderHeaders?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/salesorder/SalesOrderLines?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/SalesOrder/SalesOrderLines?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Sales/SalesPriceListVolumeDiscounts?$orderby=Timestamp&$select=...https://start.exactonline.nl/api/v1/123456/sync/Sales/SalesPriceListVolumeDiscounts?$select=https://start.exactonline.nl/api/v1/123456/sync/Subscription/SubscriptionLines?$orderby=Timestamp&$select=...Vi får samma felmeddelande här också.
Det gäller följande tabeller:
ExactOnlineREST.Incremental.TransactionLinesIncremental@eolExactOnlineREST.Incremental.GLClassificationsIncremental@eolVad är en lösning på detta?
SalesOrdersBulk fungerar här.
Men i andra tabeller återkommer samma fel itgeneor328: Incremental.AddressesIncremental.
Incremental.AccountsIncremental ger också samma felmeddelande.
Det finns för närvarande ingen lösning tillgänglig. En begäran har skickats till Exact Online för att eskalera problemet och/eller återställa den brytande ändringen.
För små tabeller kan det vara möjligt att ersätta *Incremental med motsvarande bulk-tabell eller mycket långsammare DDL-tabeller. Detta kan dock öka laddningstiden med upp till en faktor 1 000 och antalet nödvändiga API-anrop med hundratusentals per dag.
Invantive Development arbetar på att se om en patch kan skapas. Utrullningen av denna inom Invantive Cloud kommer att ske först. Utrullningen av administratörer av partners och användare kan dock ta mycket längre tid eftersom det ibland krävs ett stort versionssprång, vilket kan leda till nya problem.
Det berör nu flera hundra organisationer, och det förväntas att detta antal kommer att öka om den inkrementella cachen måste initieras om. Detta kan aldrig inträffa, men kan också inträffa i vissa miljöer redan efter några timmar.
Användningen av en tidigare oanvänd tabell kan också ge detta felmeddelande, så nya användare kommer att fastna direkt vid användning.
Så snart mer information blir tillgänglig kommer detta ämne att uppdateras.
Exact har angett att de kommer att återkalla den berörda ändringen under natten mellan 6 och 7 augusti. Vid ett senare tillfälle kommer detta att aktiveras igen, men då med extra försiktighetsåtgärder för att undvika en storskalig nedtidssituation.
Specifikt för Invantive Cloud förväntas en release tas i produktion under den 6 augusti som inte längre framkallar felmeddelandet. För partners och användare på plats kommer det också att komma en ny release, men med tanke på antalet installationer och semestertiden är rekommendationen att inkludera detta i en uppgradering vid ett senare tillfälle, eftersom orsaken kommer att försvinna under natten mellan 6 och 7 augusti.
Exact har till synes inte helt eller delvis återställt ändringen. En uppgradering av Invantive Cloud har löst de flesta problemen. Problemet kvarstår fortfarande vid:
För den senare rekommenderas det att använda den tillhörande *Incremental-tabellen som en lösning. Det kommer också en ny version där Sync-tabellerna har anpassats.
The issue has just been flagged on august 7th, 14:30 at Exact status page
In our case we updated our script by adding where Timestamp >0
create or replace table eol_rest_accountsbulk@sql
as
select *
from syncAccounts@eol
where Timestamp >0 batchsize 50000;
Tack! Skärmdump nedan. Att lägga till ett filter är en bra lösning! Det har ingen ytterligare påverkan förutom att vara en lösning för äldre versioner.
Förslaget att använda filtrering är lite konstigt med tanke på designen av synkroniserings-API:erna 
Jag har precis fått en avisering från Exact att det är löst: 
Exact Online har återställt ändringen som orsakade problemet.