Stary dobry znajomy: Oracle forms
Historia narzędzi Oracle Forms sięga późnych lat 80. i choć ich popularność wyraźnie spadła wraz z rozpowszechnieniem się Internetu, wciąż wiele aplikacji bazuje na tym rozwiązaniu. Pod wieloma względami dostępna obecnie wersja 11g niewiele przypomina te sprzed 20 lat, z drugiej jednak strony, mimo wielu dużych zmian, wciąż pełni tę samą funkcję: pozwala szybko tworzyć aplikacje bazodanowe. W tym artykule przyjrzymy się przyszłości samej technologii oraz zastanowimy się, kiedy warto się z nią rozstać i jak to zrobić.
{loadposition IT_Dzial]
Przyszłość technologii Forms
Na początek sprawa najważniejsza: Forms jest na rynku od 20 lat i prędko nie zniknie. Na rynku można usłyszeć wiele opinii i plotek na temat końca Formsów, ale oficjalny dokument mówi jasno (cytuję w oryginale, dla podkreślenia autentyczności):
Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g.
Zadowoleni użytkownicy Formsów nie mają zatem powodów do obaw – mogą dalej korzystać z tej technologii i rozwijać swoje aplikacje korzystając z nowych funkcjonalności. Dla pozostałych, w drugiej części artykułu omówimy możliwe sposoby migracji z Forms do innych rozwiązań.
Nowości w Forms 11g
Na pierwszy rzut oka największą zmianą w Forms 11g jest zmiana używanego serwera aplikacji Java z OC4J na WebLogic. Wpływ tej zmiany na tworzenie i działanie aplikacji Formsowych jest jednak minimalny, ponieważ główny komponent uruchomieniowy, Forms Server, jest napisany w C/C++, a zatem w ogóle nie jest uruchamiany w kontenerze Java. Zmigrowane zostały jedynie procesy Forms Listener Servlet i Forms Servlet, które są niewielkimi komponentami napisanymi w Javie. Zmiany odczują zatem głównie administratorzy, którzy będą musieli nauczyć się zarządzania serwerem WebLogic.
Znacznie ciekawsze, choć nie tak widoczne, są dwie nowe funkcjonalności: wsparcie dla bazodanowych kolejek AQ (Advanced Queuing) oraz wsparcie dwukierunkowej komunikacji z JavaScriptem znajdującym się na stronie z formatką. Wsparcie dla AQ umożliwia wywoływanie kodu Forms z zewnątrz – np. z procesu BPEL. Po odczytaniu komunikatu z kolejki, serwer Forms wywołuje nowy trigger WHEN-EVENT-RAISED, który obsługuje zdarzenie. Ponieważ Formsy działają w trybie żądanie-odpowiedź, pojawił się także nowy parametr MAX_EVENT_WAIT, który określa maksymalny czas od pojawienia się zdarzenia w kolejce, do jego obsłużenia. Komunikacja między formatką a JavaScriptem pozwala z kolei na wywoływanie zdarzeń z zewnątrz, ale na poziomie interfejsu użytkownika. Możemy zatem przygotować stronę, na której osadzona będzie formatka oraz dowolny inny kod HTML, który będzie wywoływał zdarzenia w formatce i na przykład przekazywał do formatki wartości pól, które użytkownik wypełnił poza formatką. Możliwa jest także komunikacja w drugą stronę – formatka (lub Forms trigger) może wywołać dowolny kod JavaScript, na przykład odświeżenie fragmentów strony znajdujących się obok formatki. Korzystając z tej możliwości można teoretycznie całkowicie ukryć przed użytkownikiem aplet Forms, przygotowując nowy interfejs użytkownika, który jednak wszystkie operacje będzie przekazywał do apletu w celu obsłużenia logiki biznesowej.
Opisane powyżej nowe funkcje ułatwiają integrowanie aplikacji Forms z bardziej nowoczesnymi technologiami oraz z narzędziami SOA – takimi, jak szyny usług i silniki procesów biznesowych. Choć od dawna możliwe jest wywoływanie kodu Java z poziomu Forms (poprzez Forms Java Importer), to nowe możliwości powodują, że rzadziej będzie to konieczne. Z drugiej strony 11g upraszcza tworzenie zaawansowanych rozszerzeń w Javie, gdy faktycznie są one potrzebne. Inne zmiany wprowadzone w Forms 11g, to przede wszystkim ulepszone mechanizmy diagnostyczne i narzędzia administracyjne.
Migrować, czy nie migrować
Istnieje przynajmniej kilka dobrych powodów, które mogą nas skłonić do odejścia od Formsów (większość z nich dotyczy także innych technologii poprzedniej generacji). Przede wszystkim na rynku jest coraz mniej osób programujących w Forms. Nie ma raczej co liczyć na absolwentów, czy samouków, a rywalizacja o doświadczonych programistów będzie się zaostrzać - tak, jak niegdyś o osoby znające COBOLa. Po drugie, choć Formsy przez lata ewoluowały wraz z całym światem IT, to jednak nie wpisują się idealnie we współczesne trendy komponentowych aplikacji webowych, czy architektury SOA (choć wersja 11g jest krokiem naprzód w tym zakresie). I chociaż bez problemu możemy z Forms wywoływać web services, a także udostępniać logikę biznesową aplikacji Forms jako usługę, to jednak Formsy od początku były tworzone jako narzędzie dla aplikacji bazodanowych. Jeśli zatem nasza aplikacja ma korzystać z różnych źródeł danych, komunikować się z wieloma innymi aplikacjami i integrować na poziomie interfejsu użytkownika, to prawdopodobnie Forms nie jest najlepszym wyborem.
Sposób migracji
Istnieją dwie zasadnicze ścieżki migracji: ewolucyjna i rewolucyjna. Pierwsza polega na integrowaniu Formsów z modułami napisanymi w innych technologiach i stopniowym przepisywaniu poszczególnych formatek. Druga, to całkowite odejście od Forms w jednym kroku. Ścieżka ewolucyjna pozwala oswoić się z nowym środowiskiem i przećwiczyć proces migracji na mniej krytycznych modułach aplikacji, zanim zabierzemy się za przepisywanie tych najważniejszych. Podejście rewolucyjne wymaga dobrej znajomości docelowego stosu technologicznego, oswojenia użytkowników z nowym środowiskiem oraz odpowiedniego podejścia do osób, które dotychczas rozwijały aplikację (przeszkolenie ich w zakresie nowych narzędzi lub znalezienie dla nich nowych zajęć, by nie stracić wiedzy zdobytej przez nich przez lata rozwoju i eksploatacji systemu). Jeśli nadal używamy Formsów w wersji klient-serwer, a chcemy przejść do środowiska webowego, to prawdopodobnie nie obejdzie się jednak bez rewolucji.
Kiedy nakreślimy już proces migracji, pozostaje pytanie: w jaki sposób przenosić poszczególne komponenty do nowego środowiska? Do wyboru mamy oczywiście migrację manualną, która jest niczym innym, jak napisaniem aplikacji od nowa. Podczas przepisywania możemy nie tylko zmienić technologię, ale również przemyśleć na nowo interfejs użytkownika i oczyścić aplikację z elementów, które nawarstwiły się przez lata i niepotrzebnie komplikowały implementację. Z drugiej strony trzeba się liczyć z tym, że pisząc wiele rzeczy od nowa, popełnimy nowe błędy, a prawdopodobnie także powielimy stare, które były już kiedyś rozwiązane.
Z pomocą przychodzą narzędzia automatyzujące migrację. Osoby liczące na całkowicie automatyczne przeniesienie aplikacji Forms, na przykład do Java EE, będą jednak rozczarowane. Żadne dostępne na rynku narzędzie nie podejmie za nas decyzji, czy określona funkcjonalność powinna być zaimplementowana jak dotychczas w PL/SQL, czy przeniesiona do warstwy aplikacji. Tym bardziej żadne narzędzie nie przepisze kodu PL/SQL do Javy. Narzędzia pomogą nam jednak stworzyć funkcjonalny prototyp nowej aplikacji, mogą z dużą dokładnością stworzyć nowy interfejs użytkownika zbliżony do poprzedniego, jak również wskażą miejsca, które wymagają ręcznej pracy.
Narzędzia wspierające
Na rynku dostępnych jest przynajmniej kilka narzędzi wspierających migrację z Forms do innych technologii. Tutaj chciałbym się skupić na dwóch, które dostarczane są przez Oracle. Po pierwsze, do dyspozycji mamy rozszerzenie środowiska JDeveloper o nazwie JHeadstart. JHeadstart potrafi na podstawie formatek stworzyć działającą aplikację Java EE wykorzystującą framework ADF, posiadającą interfejs użytkownika zaimplementowany w JSF (ADF Faces), ale zbliżony do oryginalnej aplikacji w zakresie rozłożenia elementów na stronie i nawigacji. Aplikacja taka ma także dostęp do bazy danych – podstawowe operacje odczytu, zapisu czy wyszukiwania danych powinny działać automatycznie, podobnie jak listy wartości i inne typowe elementy formatek. Logika biznesowa pozostaje jako kod PL/SQL, więc należy albo ręcznie przepisać ją do Javy (lub innego języka), albo wywoływać w niezmienionej postaci (potencjalnie wystawiając ją jako web service). Dalszy rozwój aplikacji może odbywać się w oparciu o dowolne narzędzia środowiska Java EE, choć w zakresie IDE zalecany jest JDeveloper (jako jedyny posiada specjalne wsparcie dla frameworku ADF). Nie przeszkadza to jednak używać także innych środowisk i frameworków. Co ważne, JHeadstart nie generuje żadnego kodu Java, a jedynie pliki XML, dzięki czemu nie trzeba utrzymywać generowanego automatycznie kodu (co zwykle jest dość trudne). JHeadstart jest także, a nawet przede wszystkim, narzędziem do wysokopoziomowego tworzenia aplikacji w oparciu o ADF. Koncepcyjnie można go porównać do narzędzia Designer ze świata Formsów, który również pozwala na podstawie schematu bazy danych, wysokopoziomowej definicji funkcjonalności oraz szablonów (stron, formularzy, zakładek, przycisków, etc.), wygenerować działającą aplikację. Możemy ją następnie dowolnie modyfikować w JDeveloperze, a nasze poprawki przenieść do szablonów JHeadstarta, by zostały uwzględnione przy następnej generacji. Oczywiście możemy także po wstępnej migracji JHeadstartem zrezygnować całkowicie z tego narzędzia i dalej rozwijać aplikację typowymi narzędziami ze świata Java EE. JHeadstart może ułatwić migrację do całkowicie nowego świata – technologii Java EE. Jeśli jednak chcemy pożegnać się z Formsami, ale pozostać w świecie baz danych i języka PL/SQL, to możemy skorzystać z narzędzia Application Express (APEX) – darmowego dodatku do bazy danych Oracle. APEX pozwala tworzyć aplikacje WWW bezpośrednio w bazie danych (nie wymaga serwera aplikacji, a jedynie serwera HTTP, który jest dołączony do bazy danych). APEX potrafi migrować aplikacje Forms (jak również MS Access i Excel) do bazy danych Oracle i udostępniać je przez WWW. Podobnie jak w przypadku JHeadstarta, migracja skomplikowanych formatek będzie wymagała ręcznej pracy, ale dzięki częściowej automatyzacji możemy wyraźnie skrócić czas migracji. Dalszy rozwój aplikacji odbywa się w tym przypadku poprzez edycję kodu PL/SQL z logiką biznesową oraz wykorzystanie narzędzia APEX w zakresie interfejsu użytkownika (generowany jest kod PL/SQL, który z kolei w czasie działania generuje HTML).
Podsumowanie
Oracle Forms zdobyły sobie przez lata wielu zagorzałych zwolenników. Z drugiej strony dynamiczny rozwój rynku i technologii internetowych powoduje, że nieliczne firmy decydują się na rozwijanie nowych aplikacji w tej technologii. Znacznie częściej słyszymy pytania o to, kiedy i w jaki sposób należałoby zrezygnować z Formsów w istniejących aplikacjach. Najkrótsza odpowiedź: pośpiechu nie ma, ale warto zastanowić się co zyskujemy, a co tracimy wybierając Formsy. Jak wiadomo, kiedy mamy tylko młotek, wszystko wygląda jak gwóźdź. Innymi słowy, im więcej narzędzi znamy, tym lepiej potrafimy rozwiązywać rozmaite problemy, które przed nami stoją.
Źródło: http://oracle-pl.blogspot.com/
Na początek sprawa najważniejsza: Forms jest na rynku od 20 lat i prędko nie zniknie. Na rynku można usłyszeć wiele opinii i plotek na temat końca Formsów, ale oficjalny dokument mówi jasno (cytuję w oryginale, dla podkreślenia autentyczności):
Oracle has no plan to desupport these products. Furthermore, new version of Oracle Forms, Oracle Reports will continue to be released as part of Oracle Fusion Middleware and Oracle Forms 11g and Oracle Reports 11g are components of Oracle Fusion Middleware 11g.
Zadowoleni użytkownicy Formsów nie mają zatem powodów do obaw – mogą dalej korzystać z tej technologii i rozwijać swoje aplikacje korzystając z nowych funkcjonalności. Dla pozostałych, w drugiej części artykułu omówimy możliwe sposoby migracji z Forms do innych rozwiązań.
Nowości w Forms 11g
Na pierwszy rzut oka największą zmianą w Forms 11g jest zmiana używanego serwera aplikacji Java z OC4J na WebLogic. Wpływ tej zmiany na tworzenie i działanie aplikacji Formsowych jest jednak minimalny, ponieważ główny komponent uruchomieniowy, Forms Server, jest napisany w C/C++, a zatem w ogóle nie jest uruchamiany w kontenerze Java. Zmigrowane zostały jedynie procesy Forms Listener Servlet i Forms Servlet, które są niewielkimi komponentami napisanymi w Javie. Zmiany odczują zatem głównie administratorzy, którzy będą musieli nauczyć się zarządzania serwerem WebLogic.
Znacznie ciekawsze, choć nie tak widoczne, są dwie nowe funkcjonalności: wsparcie dla bazodanowych kolejek AQ (Advanced Queuing) oraz wsparcie dwukierunkowej komunikacji z JavaScriptem znajdującym się na stronie z formatką. Wsparcie dla AQ umożliwia wywoływanie kodu Forms z zewnątrz – np. z procesu BPEL. Po odczytaniu komunikatu z kolejki, serwer Forms wywołuje nowy trigger WHEN-EVENT-RAISED, który obsługuje zdarzenie. Ponieważ Formsy działają w trybie żądanie-odpowiedź, pojawił się także nowy parametr MAX_EVENT_WAIT, który określa maksymalny czas od pojawienia się zdarzenia w kolejce, do jego obsłużenia. Komunikacja między formatką a JavaScriptem pozwala z kolei na wywoływanie zdarzeń z zewnątrz, ale na poziomie interfejsu użytkownika. Możemy zatem przygotować stronę, na której osadzona będzie formatka oraz dowolny inny kod HTML, który będzie wywoływał zdarzenia w formatce i na przykład przekazywał do formatki wartości pól, które użytkownik wypełnił poza formatką. Możliwa jest także komunikacja w drugą stronę – formatka (lub Forms trigger) może wywołać dowolny kod JavaScript, na przykład odświeżenie fragmentów strony znajdujących się obok formatki. Korzystając z tej możliwości można teoretycznie całkowicie ukryć przed użytkownikiem aplet Forms, przygotowując nowy interfejs użytkownika, który jednak wszystkie operacje będzie przekazywał do apletu w celu obsłużenia logiki biznesowej.
Opisane powyżej nowe funkcje ułatwiają integrowanie aplikacji Forms z bardziej nowoczesnymi technologiami oraz z narzędziami SOA – takimi, jak szyny usług i silniki procesów biznesowych. Choć od dawna możliwe jest wywoływanie kodu Java z poziomu Forms (poprzez Forms Java Importer), to nowe możliwości powodują, że rzadziej będzie to konieczne. Z drugiej strony 11g upraszcza tworzenie zaawansowanych rozszerzeń w Javie, gdy faktycznie są one potrzebne. Inne zmiany wprowadzone w Forms 11g, to przede wszystkim ulepszone mechanizmy diagnostyczne i narzędzia administracyjne.
Migrować, czy nie migrować
Istnieje przynajmniej kilka dobrych powodów, które mogą nas skłonić do odejścia od Formsów (większość z nich dotyczy także innych technologii poprzedniej generacji). Przede wszystkim na rynku jest coraz mniej osób programujących w Forms. Nie ma raczej co liczyć na absolwentów, czy samouków, a rywalizacja o doświadczonych programistów będzie się zaostrzać - tak, jak niegdyś o osoby znające COBOLa. Po drugie, choć Formsy przez lata ewoluowały wraz z całym światem IT, to jednak nie wpisują się idealnie we współczesne trendy komponentowych aplikacji webowych, czy architektury SOA (choć wersja 11g jest krokiem naprzód w tym zakresie). I chociaż bez problemu możemy z Forms wywoływać web services, a także udostępniać logikę biznesową aplikacji Forms jako usługę, to jednak Formsy od początku były tworzone jako narzędzie dla aplikacji bazodanowych. Jeśli zatem nasza aplikacja ma korzystać z różnych źródeł danych, komunikować się z wieloma innymi aplikacjami i integrować na poziomie interfejsu użytkownika, to prawdopodobnie Forms nie jest najlepszym wyborem.
Sposób migracji
Istnieją dwie zasadnicze ścieżki migracji: ewolucyjna i rewolucyjna. Pierwsza polega na integrowaniu Formsów z modułami napisanymi w innych technologiach i stopniowym przepisywaniu poszczególnych formatek. Druga, to całkowite odejście od Forms w jednym kroku. Ścieżka ewolucyjna pozwala oswoić się z nowym środowiskiem i przećwiczyć proces migracji na mniej krytycznych modułach aplikacji, zanim zabierzemy się za przepisywanie tych najważniejszych. Podejście rewolucyjne wymaga dobrej znajomości docelowego stosu technologicznego, oswojenia użytkowników z nowym środowiskiem oraz odpowiedniego podejścia do osób, które dotychczas rozwijały aplikację (przeszkolenie ich w zakresie nowych narzędzi lub znalezienie dla nich nowych zajęć, by nie stracić wiedzy zdobytej przez nich przez lata rozwoju i eksploatacji systemu). Jeśli nadal używamy Formsów w wersji klient-serwer, a chcemy przejść do środowiska webowego, to prawdopodobnie nie obejdzie się jednak bez rewolucji.
Kiedy nakreślimy już proces migracji, pozostaje pytanie: w jaki sposób przenosić poszczególne komponenty do nowego środowiska? Do wyboru mamy oczywiście migrację manualną, która jest niczym innym, jak napisaniem aplikacji od nowa. Podczas przepisywania możemy nie tylko zmienić technologię, ale również przemyśleć na nowo interfejs użytkownika i oczyścić aplikację z elementów, które nawarstwiły się przez lata i niepotrzebnie komplikowały implementację. Z drugiej strony trzeba się liczyć z tym, że pisząc wiele rzeczy od nowa, popełnimy nowe błędy, a prawdopodobnie także powielimy stare, które były już kiedyś rozwiązane.
Z pomocą przychodzą narzędzia automatyzujące migrację. Osoby liczące na całkowicie automatyczne przeniesienie aplikacji Forms, na przykład do Java EE, będą jednak rozczarowane. Żadne dostępne na rynku narzędzie nie podejmie za nas decyzji, czy określona funkcjonalność powinna być zaimplementowana jak dotychczas w PL/SQL, czy przeniesiona do warstwy aplikacji. Tym bardziej żadne narzędzie nie przepisze kodu PL/SQL do Javy. Narzędzia pomogą nam jednak stworzyć funkcjonalny prototyp nowej aplikacji, mogą z dużą dokładnością stworzyć nowy interfejs użytkownika zbliżony do poprzedniego, jak również wskażą miejsca, które wymagają ręcznej pracy.
Narzędzia wspierające
Na rynku dostępnych jest przynajmniej kilka narzędzi wspierających migrację z Forms do innych technologii. Tutaj chciałbym się skupić na dwóch, które dostarczane są przez Oracle. Po pierwsze, do dyspozycji mamy rozszerzenie środowiska JDeveloper o nazwie JHeadstart. JHeadstart potrafi na podstawie formatek stworzyć działającą aplikację Java EE wykorzystującą framework ADF, posiadającą interfejs użytkownika zaimplementowany w JSF (ADF Faces), ale zbliżony do oryginalnej aplikacji w zakresie rozłożenia elementów na stronie i nawigacji. Aplikacja taka ma także dostęp do bazy danych – podstawowe operacje odczytu, zapisu czy wyszukiwania danych powinny działać automatycznie, podobnie jak listy wartości i inne typowe elementy formatek. Logika biznesowa pozostaje jako kod PL/SQL, więc należy albo ręcznie przepisać ją do Javy (lub innego języka), albo wywoływać w niezmienionej postaci (potencjalnie wystawiając ją jako web service). Dalszy rozwój aplikacji może odbywać się w oparciu o dowolne narzędzia środowiska Java EE, choć w zakresie IDE zalecany jest JDeveloper (jako jedyny posiada specjalne wsparcie dla frameworku ADF). Nie przeszkadza to jednak używać także innych środowisk i frameworków. Co ważne, JHeadstart nie generuje żadnego kodu Java, a jedynie pliki XML, dzięki czemu nie trzeba utrzymywać generowanego automatycznie kodu (co zwykle jest dość trudne). JHeadstart jest także, a nawet przede wszystkim, narzędziem do wysokopoziomowego tworzenia aplikacji w oparciu o ADF. Koncepcyjnie można go porównać do narzędzia Designer ze świata Formsów, który również pozwala na podstawie schematu bazy danych, wysokopoziomowej definicji funkcjonalności oraz szablonów (stron, formularzy, zakładek, przycisków, etc.), wygenerować działającą aplikację. Możemy ją następnie dowolnie modyfikować w JDeveloperze, a nasze poprawki przenieść do szablonów JHeadstarta, by zostały uwzględnione przy następnej generacji. Oczywiście możemy także po wstępnej migracji JHeadstartem zrezygnować całkowicie z tego narzędzia i dalej rozwijać aplikację typowymi narzędziami ze świata Java EE. JHeadstart może ułatwić migrację do całkowicie nowego świata – technologii Java EE. Jeśli jednak chcemy pożegnać się z Formsami, ale pozostać w świecie baz danych i języka PL/SQL, to możemy skorzystać z narzędzia Application Express (APEX) – darmowego dodatku do bazy danych Oracle. APEX pozwala tworzyć aplikacje WWW bezpośrednio w bazie danych (nie wymaga serwera aplikacji, a jedynie serwera HTTP, który jest dołączony do bazy danych). APEX potrafi migrować aplikacje Forms (jak również MS Access i Excel) do bazy danych Oracle i udostępniać je przez WWW. Podobnie jak w przypadku JHeadstarta, migracja skomplikowanych formatek będzie wymagała ręcznej pracy, ale dzięki częściowej automatyzacji możemy wyraźnie skrócić czas migracji. Dalszy rozwój aplikacji odbywa się w tym przypadku poprzez edycję kodu PL/SQL z logiką biznesową oraz wykorzystanie narzędzia APEX w zakresie interfejsu użytkownika (generowany jest kod PL/SQL, który z kolei w czasie działania generuje HTML).
Podsumowanie
Oracle Forms zdobyły sobie przez lata wielu zagorzałych zwolenników. Z drugiej strony dynamiczny rozwój rynku i technologii internetowych powoduje, że nieliczne firmy decydują się na rozwijanie nowych aplikacji w tej technologii. Znacznie częściej słyszymy pytania o to, kiedy i w jaki sposób należałoby zrezygnować z Formsów w istniejących aplikacjach. Najkrótsza odpowiedź: pośpiechu nie ma, ale warto zastanowić się co zyskujemy, a co tracimy wybierając Formsy. Jak wiadomo, kiedy mamy tylko młotek, wszystko wygląda jak gwóźdź. Innymi słowy, im więcej narzędzi znamy, tym lepiej potrafimy rozwiązywać rozmaite problemy, które przed nami stoją.
Źródło: http://oracle-pl.blogspot.com/
Autor: Michał Kuratczyk
Najnowsze wiadomości
Kwantowy przełom w cyberochronie - nadchodząca dekada przepisze zasady szyfrowania na nowo
Przez długi czas cyfrowe bezpieczeństwo opierało się na prostym założeniu: współczesne komputery potrzebowałyby ogromnych zasobów i wielu lat, aby złamać silne algorytmy szyfrowania. Rozwój technologii kwantowej zaczyna jednak tę regułę podważać, a eksperci przewidują, że w perspektywie 5–10 lat może nadejść „dzień zero”. Jest to moment, w którym zaawansowana maszyna kwantowa będzie w stanie przełamać większość aktualnie stosowanych zabezpieczeń kryptograficznych w czasie liczonym nie w latach, lecz w godzinach.
PSI prezentuje nową identyfikację wizualną
W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.
W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.
PROMAG S.A. rozpoczyna wdrożenie systemu ERP IFS Cloud we współpracy z L-Systems
PROMAG S.A., lider w obszarze intralogistyki, rozpoczął wdrożenie systemu ERP IFS Cloud, który ma wesprzeć dalszy rozwój firmy oraz integrację kluczowych procesów biznesowych. Projekt realizowany jest we współpracy z firmą L-Systems i obejmuje m.in. obszary finansów, produkcji, logistyki, projektów oraz serwisu, odpowiadając na rosnącą skalę i złożoność realizowanych przedsięwzięć.
F5 rozszerza portfolio bezpieczeństwa o narzędzia do ochrony systemów AI w środowiskach enterprise
F5 ogłosiło wprowadzenie dwóch nowych rozwiązań - F5 AI Guardrails oraz F5 AI Red Team - które mają odpowiedzieć na jedno z kluczowych wyzwań współczesnych organizacji: bezpieczne wdrażanie i eksploatację systemów sztucznej inteligencji na dużą skalę. Nowa oferta łączy ochronę działania modeli AI w czasie rzeczywistym z ofensy
Snowflake + OpenAI: AI bliżej biznesu
Snowflake przyspiesza wykorzystanie danych i sztucznej inteligencji w firmach, przenosząc AI z fazy eksperymentów do codziennych procesów biznesowych. Nowe rozwiązania w ramach AI Data Cloud integrują modele AI bezpośrednio z danymi, narzędziami deweloperskimi i warstwą semantyczną. Partnerstwo z OpenAI, agent Cortex Code, Semantic View Autopilot oraz rozwój Snowflake Postgres pokazują, jak budować skalowalne, bezpieczne i mierzalne wdrożenia AI w skali całej organizacji.
Najnowsze artykuły
Magazyn bez błędów? Sprawdź, jak system WMS zmienia codzienność logistyki
Współczesna logistyka wymaga nie tylko szybkości działania, lecz także maksymalnej precyzji – to właśnie te czynniki coraz częściej decydują o przewadze konkurencyjnej firm. Nawet drobne pomyłki w ewidencji stanów magazynowych, błędy przy przyjmowaniu dostaw czy nieprawidłowe rozmieszczenie towarów, mogą skutkować poważnymi stratami finansowymi i opóźnieniami w realizacji zamówień. W jaki sposób nowoczesne rozwiązania do zarządzania pomagają unikać takich sytuacji? Czym właściwie różni się tradycyjny system magazynowy od zaawansowanych rozwiązań klasy WMS (ang. Warehouse Management System)? I w jaki sposób inteligentne zarządzanie procesami magazynowymi realnie usprawnia codzienną pracę setek firm?
Współczesna logistyka wymaga nie tylko szybkości działania, lecz także maksymalnej precyzji – to właśnie te czynniki coraz częściej decydują o przewadze konkurencyjnej firm. Nawet drobne pomyłki w ewidencji stanów magazynowych, błędy przy przyjmowaniu dostaw czy nieprawidłowe rozmieszczenie towarów, mogą skutkować poważnymi stratami finansowymi i opóźnieniami w realizacji zamówień. W jaki sposób nowoczesne rozwiązania do zarządzania pomagają unikać takich sytuacji? Czym właściwie różni się tradycyjny system magazynowy od zaawansowanych rozwiązań klasy WMS (ang. Warehouse Management System)? I w jaki sposób inteligentne zarządzanie procesami magazynowymi realnie usprawnia codzienną pracę setek firm?
Migracja z SAP ECC na S4 HANA: Ryzyka, korzyści i alternatywne rozwiązania
W ostatnich latach wiele firm, które korzystają z systemu SAP ECC (Enterprise Central Component), stoi przed decyzją o przejściu na nowszą wersję — SAP S4 HANA. W obliczu końca wsparcia dla ECC w 2030 roku, temat ten staje się coraz bardziej aktualny. Przemiany technologiczne oraz rosnące oczekiwania związane z integracją nowych funkcji, jak sztuczna inteligencja (AI), skłaniają do refleksji nad tym, czy warto podjąć tak dużą zmianę w architekturze systemu. Przyjrzyjmy się głównym powodom, dla których firmy rozważają migrację do S4 HANA, ale także argumentom, które mogą przemawiać za pozostaniem przy dotychczasowym systemie ECC, przynajmniej na krótki okres.
Jak maksymalizować zyski z MTO i MTS dzięki BPSC ERP?
Zysk przedsiębiorstwa produkcyjnego zależy nie tylko od wydajności maszyn, ale przede wszystkim od precyzyjnego planowania, realnych danych i umiejętnego zarządzania procesami. Dlatego firmy, które chcą skutecznie działać zarówno w modelu Make to Stock (MTS), jak i Make to Order (MTO), coraz częściej sięgają po rozwiązania klasy ERP, takie jak BPSC ERP.
Zysk przedsiębiorstwa produkcyjnego zależy nie tylko od wydajności maszyn, ale przede wszystkim od precyzyjnego planowania, realnych danych i umiejętnego zarządzania procesami. Dlatego firmy, które chcą skutecznie działać zarówno w modelu Make to Stock (MTS), jak i Make to Order (MTO), coraz częściej sięgają po rozwiązania klasy ERP, takie jak BPSC ERP.
Ponad połowa cyberataków zaczyna się od błędu człowieka
Ponad 2/3 firm w Polsce odnotowała w zeszłym roku co najmniej 1 incydent naruszenia bezpieczeństwa . Według danych Unit 42, zespołu analitycznego Palo Alto Networks, aż 60% ataków rozpoczyna się od działań wymierzonych w pracowników – najczęściej pod postacią phishingu i innych form inżynierii społecznej . To pokazuje, że w systemie ochrony organizacji pracownicy są kluczowym ogniwem – i że firmy muszą nie tylko edukować, ale też konsekwentnie egzekwować zasady cyberhigieny. Warto o tym pamiętać szczególnie teraz, w październiku, gdy obchodzimy Europejski Miesiąc Cyberbezpieczeństwa.
MES - holistyczne zarządzanie produkcją
Nowoczesna produkcja wymaga precyzji, szybkości i pełnej kontroli nad przebiegiem procesów. Rosnąca złożoność zleceń oraz presja kosztowa sprawiają, że ręczne raportowanie i intuicyjne zarządzanie coraz częściej okazują się niewystarczające. Firmy szukają rozwiązań, które umożliwiają im widzenie produkcji „na żywo”, a nie z opóźnieniem kilku godzin czy dni. W tym kontekście kluczową rolę odgrywają narzędzia, które porządkują informacje i pozwalają reagować natychmiast, zamiast po fakcie.
Infrastruktura w punkcie zwrotnym - 5 prognoz kształtujących AI, odporność i suwerenność danych w 2026 roku
W 2026 roku zyskają firmy, które traktują infrastrukturę nie jako obszar generujący koszty, lecz ja… / Czytaj więcej
Tylko 7% firm w Europie wykorzystuje w pełni potencjał AI
72% firm w regionie EMEA uznaje rozwój narzędzi bazujących na sztucznej inteligencji za priorytet s… / Czytaj więcej
Chmura publiczna w Unii Europejskiej – między innowacją a odpowiedzialnością za dane
Transformacja cyfrowa w Europie coraz mocniej opiera się na chmurze publicznej, która stała się fun… / Czytaj więcej
Jak Cisco pomaga Europie spłacić dług technologiczny w krytycznej infrastrukturze sieciowej
Cyfryzacja, rozwój sztucznej inteligencji i nadchodzące komputery kwantowe wymagają od Europy stabi… / Czytaj więcej
MŚP inwestują w AI, kompetencje pracowników nadal wyzwaniem
Europejskie małe i średnie firmy coraz śmielej inwestują w sztuczną inteligencję, ale to kompetencj… / Czytaj więcej
AP EU AI Cloud: nowy standard suwerennej chmury i AI dla europejskich organizacji
SAP EU AI Cloud to zapowiedziana 27 listopada 2025 r. platforma, która łączy dotychczasowe inicjaty… / Czytaj więcej
