## Zusammenfassung Wenn man über das RestAPI die Auftragsliste abruft, und Aufträge "ohne Termin" dabei sind, erhält man nur 500 Internal Server Error zurück. ## Schritte zum Reproduzieren Getestet wurde Version 1.1.6. Soweit ersichtlich gab es aber in den neueren Versionen keine Code-Änderung diesbezüglich. Zunächst braucht man einen Auftrag ohne Termin. Die Anzeige "Termin" im Modul "Auftrag", Reiter "1 Auswahl) muss bei mindestens einem Auftrag leer sein. Das scheint von den Positionen abzuhängen: - Auftrag anlegen (mit dem Blatt-Symbol) =\> Auftrag hat in der Auftragsliste keinen "Termin" - Position zu Auftrag hinzufügen =\> Auftrag hat in der Auftragsliste einen Termin, nämlich den Termin dieser Position (auch wenn er vom Liefertermin in den Kopfdaten abweicht) - Zweite Position zu Auftrag hinzufügen =\> Auftrag hat in der Auftragsliste den Termin der früheren Position - Lieferschein erstellen, wo nur eine Position aufgenommen wird =\> Auftrag hat in der Auftragsliste den Termin der verbliebenen Position - Lieferschein um die zweite Position ergänzen =\> Auftrag hat in der Auftragsliste keinen "Termin" mehr Wenn man solch einen Auftrag ohne Termin hat, ruft man über das RestAPI eine Liste von Aufträgen ab, wahlweise auch gefiltert auf diesen einen Auftrag ohne Termin, hier z.B. Auftrag "25/0000092": ``` http://[...]:8080/kieselstein-rest/services/rest/api/v1/order?filter_cnr=25%2F0000092&userid=[...] ``` ## Modul, Maske, Terminal, API-Aufruf, Bericht Das Problem ist das RestAPI "order". Die problemverursachenden Aufträge kann man aber auch über den Client, Modul "Auftrag", Reiter "1 Auswahl" finden. ## Wie ist das aktuelle Fehlerverhalten? HTTP-Status-Code 500 wird zurückgegeben, mit folgenden Response Header: ``` connection: keep-alive content-length: 0 date: Tue,16 Dec 2025 13:44:42 GMT x-hv-error-code: 10 ``` ## Was ist das erwartete richtige Verhalten? Eine Liste der Aufträge hätte zurückgegeben werden sollen. ## Relevante Log-Dateien und/oder Screenshots ``` 2025-12-16 14:44:42,378 ERROR [default task-5] (HvThrowableExceptionMapper.java:18) - default-log java.lang.NullPointerException at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.order.OrderEntryTransformer.transformOne(OrderEntryTransformer.java:51) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.order.OrderEntryTransformer.transformOne(OrderEntryTransformer.java:41) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.BaseFLRTransformer.transformAll(BaseFLRTransformer.java:67) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.BaseFLRTransformerFeatureData.transformAll(BaseFLRTransformerFeatureData.java:17) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.BaseFLRTransformer.transform(BaseFLRTransformer.java:56) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.factory.query.BaseQuery.transform(BaseQuery.java:69) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.factory.query.AuftragQuery.transform(AuftragQuery.java:77) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.factory.query.BaseQuery.getResultList(BaseQuery.java:65) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.factory.query.BaseQuery$$FastClassBySpringCGLIB$$f25a14d6.invoke(<generated>) at deployment.kieselstein-1.1.6.ear//org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:218) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:783) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.support.DelegatingIntroductionInterceptor.doProceed(DelegatingIntroductionInterceptor.java:136) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.support.DelegatingIntroductionInterceptor.invoke(DelegatingIntroductionInterceptor.java:124) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.proceed(CglibAopProxy.java:753) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:698) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.factory.query.AuftragQuery$$EnhancerBySpringCGLIB$$4d7a8118.getResultList(<generated>) at deployment.kieselstein-1.1.6.ear.kieselstein-rest-1.1.6.war//com.heliumv.api.order.OrderService.getOrders(OrderService.java:55) [...] ``` ## Mögliche Korrekturen OrderEntryTransformer.java ``` entry.setDeliveryDateMs(((Date) flrObject[6]).getTime()) ; // hier wird die Exception geworfen ``` Soweit ich sehe würde es reichen, in OrderEntryTransformer.java auf null zu prüfen, bevor "getTime()" aufgerufen wird. Grundsätzlich wäre es aber auch denkbar, dass man an dieser Stelle nicht das Datum der frühesten auszuliefernden Position zurückgibt (was null sein kann), sondern das Datum, was im Auftrag als Liefertermin hinterlegt ist. Der Feldname "DeliveryDate" ist an der Stelle nicht eindeutig, und ich hatte auf Anhieb letzteres erwartet. Wenn das eigentlich der Plan war, und weil das ein Pflichtfeld ist nicht auf null geprüft wurde, dann müsste man wahrscheinlich an der Datenbankabfrage ansetzen: OrderService.java ``` QueryResult result = orderQuery.setQuery(params) ; List<OrderEntry> orders = orderQuery.getResultList(result) ; // hier wird die Abfrage ausgelöst return orders; ``` ## Workaround Man kann die Aufträge auch einfach direkt aus der Postgresql-Datenbank auslesen, Tabelle "auft_auftrag". Das mache ich jetzt, insofern hat es für mich persönlich keine Dringlichkeit.