Der Rechtsstreit zwischen Crytek und Cloud Imperium Games nimmt eine kuriose Wende: Auf einmal ist unklar, ob das Weltraumspiel Squadron 42 als eigenständiges Programm oder doch irgendwie als Teil von Star Citizen erscheint. (Star Citizen, Crysis)
Quelle: Golem
Wenn jemand mit reinen Zahlen beeindrucken möchte, dann MSI: Das GS66 hat einen sehr großen Akku und ein Display mit 300 Hz Bildfrequenz. Dabei soll das Gaming-Notebook trotzdem möglichst schlank ausfallen. (MSI, Notebook)
Quelle: Golem
Razers neuer Gaming-PC ist gerade groß genug für eine Grafikkarte in voller Größe. Die restlichen Komponenten werden vom integrierten Intel-NUC9 gestellt, der SSD, RAM und eine 45-Watt-CPU vereint. Das macht den Tomahawk Gaming Desktop ziemlich kompakt. (Razer, Prozessor)
Quelle: Golem
Mehrere Banken haben verbindlich erklärt, einen Milliardenkredit für den Kauf von HP Inc. bereitzustellen. Als nächstes könnte ein Proxy-Kampf folgen. (HP, Drucker)
Quelle: Golem
China soll offenbar der große Markt für Tesla werden: Elon Musk war in Schanghai, um die ersten Model 3 an Kunden zu übergeben. Dabei kündigte er weitere Investitionen in China an. Unter anderem will Tesla dort ein neues Elektroauto entwickeln. (Tesla, Elektroauto)
Quelle: Golem
Tchibo hat die Leistungen aller Smartphone-Tarife aufgewertet und folgt damit einem Markttrend. In drei von vier Mobilfunktarifen erhalten Kunden ohne Aufpreis mehr ungedrosseltes Datenvolumen. (Mobilfunktarif, Mobilfunk)
Quelle: Golem
Eigentlich sind die Nutzerdaten unter iOS verschlüsselt, auch mit einem Jailbreak sollten sie nicht gelesen werden können. Der Forensiksoftware-Hersteller Elcomsoft will mit der Jailbreak-Software Checkra1n dennoch an Teile des iOS-Schlüsselbundes gelangen können. (Apple, iPhone)
Quelle: Golem
Gartner predicts that “by 2022, 70 percent of white-collar workers will interact with conversational platforms on a daily basis.” As a result, the research group found that more organizations are investing in chatbot development and deployment.
IBM Business Partners like Sopra Steria Group are making chatbot and virtual assistant technology available to businesses. Sopra Steria Group, a European leader in digital transformation, has developed an intelligent virtual assistant for organizations across several industries who want to use an AI conversational interface to answer recurrent customer service questions.
Choosing IBM AI technology
In developing our solution, we at Sopra Steria Group were looking for AI technology that was easy to configure and could support multiple languages and complex dialogs. We created a training set of 2,000 sentences such as “I would like to buy a car,” or “I would like to have a coffee,” and tested 15 different AI solutions. Of all the solutions, we found that IBM AI technologies were the most accurate and could best meet our requirements. We are now using IBM Watson Assistant, IBM Watson Language Translator, IBM Watson Natural Language Understanding and IBM Watson Text to Speech as the AI foundation for our intelligent virtual assistant accelerator.
We have developed an orchestrator and a front-end interface to manage dialogs and connectivity to external systems and functionalities, such as support for multiple languages. Our solution enables a faster deployment of customer chatbots than any other on the market because of our enhancements.
Sopra Steria developers use Red Hat OpenShift sandbox environments to experiment with new concepts and build applications for the company’s employees. It also uses the Red Hat OpenShift environment to support intelligent virtual assistants and operate other managed services for its customers.
Our intelligent virtual assistant solution is located primarily on the cloud, but it can also be located on site at a client’s location if that is what the client needs. Locating the solution on premises allows us to be able to connect the dialogs easily with internal systems like billing and HR information systems.
Accelerating deployment of the intelligent virtual assistant
The Sopra Steria Group intelligent virtual assistant accelerator engine enables our solution to be deployed rapidly. There’s an intuitive graphical user interface, so our clients can begin creating dialogs for their chatbots and using it in customer service scenarios almost immediately.
Currently the intelligent virtual assistant is live in 10 sites throughout Europe. In its most mature instance, the solution is processing 80 percent of customer queries. In the first month alone, the solution processed 75,000 conversations. The solution has scaled from 450,000 users to more than one million and a half, with the expectation of supporting three million within the coming year.
Based on 700 user evaluations of the quality of service provided by the intelligent virtual assistant at our most mature client, more than 64 percent of users felt that the treatment had been satisfactory. This is a much higher satisfaction rate than the support provided by another solution that we had implemented in the past, but that did not use Watson Assistant.
The Sopra Steria Group solution enables our clients to be available for their customers day and night, while reducing operating costs. It also frees customer service representatives to focus on more complex and high-value customer issues.
Read the case study for more details.
The post Improving customer service with an intelligent virtual assistant using IBM Watson appeared first on Cloud computing news.
Quelle: Thoughts on Cloud
This post describes the process for building and deploying the SAP Commerce platform (formerly known as SAP Hybris) application server and applications to the Red Hat OpenShift Container Platform. SAP Commerce is a comprehensive commerce platform that includes product content management, experience management, personalization and order management.
Architecture and approach
The deployment of SAP Commerce to OpenShift consists of two main components:
SAP Commerce Server
Deployed applications, components and configurations
Given that the OpenShift Container Platform leverages container images as the packaging model, a layered file system is in use which allows for a common base to be used regardless of the number of applications. Since images are atomic in nature, there is a guarantee that the same base can be replicated across all of the applications. In addition, a container delivery pipeline can be created that allows for applications to be rebuilt automatically whenever the base is updated, such as when updates are installed or a security vulnerability is discovered.
Taking advantage of this, the approach used during this post will build the application in 2 different phases:
During the first phase, the SAP Commerce ‘base image’ is built. To do that we are using a Docker Build strategy (dockerStrategy) building the container image by reading the Dockerfile specifications from our source repository. The final result will be an SAP Commerce container image stored in the OpenShift internal registry that can be used later as many times as we need.
During the second phase, the application and different components will be built and initialized using a ‘Source to Image’ (s2i) strategy where the application source will be merged with the SAP Commerce base image built during the previous phase. As a result, the custom SAP Commerce application container image will be pushed to the internal registry, so this can be used to deploy the application instance later, and reused for different environments and different purposes (Dev, QA, Prod…)
OpenShift configuration
For this post, we’re using OpenShift Container Platform 4.2. To support the build and deploy stages, we are using Nexus and a git server deployed in OpenShift. This procedure can be easily adapted to use any other artifact repository and/or source code management tool. These tools will contain the initial artifacts to build the SAP Commerce base image and the application code that will be deployed on top of that base image. Additionally we are using Secrets and Config Maps that are not part of the templates to store different credentials to login into these systems and allow us to pull in objects.
To support application portability between environments, it is recommended that application configurations be externalized and injected at runtime. This enables the core components of the application (JAR file(s) packaged into an atomic image) to have an independant lifecycle from the configurations. Configurations in SAP Commerce that both override a portion of the default server configuration and support deployed applications are specified within a file called local.properties.
OpenShift supports storing application configurations within the platform in an object called a ConfigMap and sensible data in an object called a Secret. For this use case, we are storing the application configuration that we want to change during runtime in a ConfigMap called ‘hybrisconfig’ and the sensible data in a Secret called ‘hybrislicense’.
Build and deploy process
One of the benefits of the OpenShift Container Platform is that it provides a robust build facility for creating container images. Multiple build strategies are available, giving administrators and developers the flexibility to select an option that best suits their needs.
The process to build the SAP Commerce container base image, the final application container image and the deployment of this application into the platform is fully managed by OpenShift. Templates are used (so they are reusable as many times as needed) to describe how our application is going to be built and deployed, and what objects are created in the platform. The use of ‘everything as code’ (Infrastructure as Code, Configuration as Code…) is a great practice to achieve platform automation, idempotency, reusability and portability.
All the instructions to deploy the required objects are captured in the following GitHub repository. As part of the process we need to download SAP Commerce and extract the ‘hybris’ directory to be used as the base for our SAP Commerce deployment. This is the directory we push to our Artifact Repository to be used during the SAP Commerce base image build process. For the purpose of this post a ‘develop’ environment is set up from the given config templates, but this can be adapted to your specific requirements. This initial “plain” configuration and SAP Commerce platform files, along with the instructions from our Dockerfile will form the final SAP Commerce base image.
For the final application build, the previous created base image is used. This image already has the instructions (the s2i directory previously injected) to build and run the new resultant image from this build process. During the build process the source from our Git server repository is injected in the build container and the instructions from the ‘assemble’ script are executed.
We won’t go deep into the building and customizing process for the SAP Commerce application. The best source for those resources are the SAP Help for SAP Commerce page or SAP Customer Experience Wiki.
Once the final image has been built containing the application, it can be deployed. As part of the used templates, additional objects are created in OpenShift to run the application deployments and manage the internal and external request to the application endpoints. A DeploymentConfig which already has the information of the application container image to be used as well as instructions on how this container image should be deployed is then created.
Once the application has been deployed, they will be accessible via an OpenShift Route that exposes services externally.
The post Building and running SAP Commerce in OpenShift appeared first on Red Hat OpenShift Blog.
Quelle: OpenShift
Eine riesige 128-Zoll-Leinwand, Motoren unter dem Autositz und ein Lenkrad davor: Razers Eracing Simulator erinnert an Rennspielautomaten aus Arcade-Hallen. Die Apparatur soll ein möglichst realistisches Rennerlebnis bieten. Der Hersteller plant sogar eine E-Sports-Liga dafür. (Razer, Games)
Quelle: Golem
