What OpenText announced at Enterprise World 2019 in Toronto for the InfoArchive Roadmap has already been realized by fme: Setting up a container-based infrastructure for OpenText InfoArchive.
Microservice architectures are often a graph of components distributed across a network. This architecture gives rise to a new problem. How can we trace and bind together all services involved in one operation request? When a client calls an operation, it can be spread across different services over the network, each service has its own context.
Building a search form in older versions of InfoArchive was very painful specially when building searches for linked tables (Table-based archiving). Finally, InfoArchive 16EP4 release and higher added many search composition enhancements such as:
- Ability to see column properties like Data Type, Encrypted Field, Export Enablement, Filter Enablement, Sorting and Hidden column during composition.
- Simplified nested search mapping and multiple set support
- Repeating attribute support
- Operator support and nested search visibility
- Derive from list-multi select control as a target.
- New data types support FLOAT, BIGDECIMAL, and BIGINTEGER.
Docker containers (https://www.docker.com/resources/what-container) have become an industry standard for cloud-native applications due to their smaller size and resource need compared to the VM-based solutions. Since Docker 17, it is possible to use multistage builds (https://docs.docker.com/develop/develop-images/multistage-build/) to create small scratch-based containers.
Obvious advantages of this approach are the size of the resulting container as well as a reduced surface for potential attacks due to a very limited number of components. But does using scratch also have some unexpected “side-effects”? Let’s look into this using a small Golang-based Program.
It is the 08th of July 2019 at 7:30 o’clock. At fme AG’s office in Brunswick, everything looks like it is going to be a normal Monday morning. The first employees are making themselves comfortable at their workplaces and trying to dispel their tiredness with a hot cup of coffee. Some people wonder about the whereabouts of the dishes and cutlery before going back to their desks to turn on the computer. But the supposed calm is deceptive. Because this week shouldn’t be an ordinary one.
Most DMS platforms like Documentum and SharePoint have their out-of-the-box full clients which are meant to provide all (or most of all) of the platform functionality. Although these full clients can, normally, get customized or configured, they are, however, complex and slow to adopt new technologies.
If you have a specific use case, why start from a complex system and reduce it to your needs? Why not build a custom client that is streamlined and focus on your use case instead? The business logic can reside on the server. But for the client, we are free to use any state-of-the-art modern web framework.
Monday morning, for some this is the agonizing beginning of the week and the work stress, for me this is the time of anticipation until I’m back at the fme office. Because when I go to the office in the morning; I’m already expected with a sweet smile and a “Hah, good that you’re there!”. For one or the other, these words may already scare the ToDo list. I, on the other hand, wonder what will happen this week…
So while I’m still thinking about all the adventures, I move slowly in the direction of the computer and again need tens of starts to type in the password correctly. After successfully completing the mission, I discuss today’s daily routine with my colleague. Once this is done, it goes to the preserves.
With so many applications/systems to keep an eye on, nowadays, it often takes IT staff too much time to perform repeated manual tasks. This is valuable time we then lack in communicating with stake holders, key users and operational departments or solving other problems.
It’s often easy to say: “I’ll just do this manually because it only takes me half an hour a week”
The old OpenText Documentum Webtop versions (older than 6.8.2) were using Content Transfer Applet, and clients have been complaining about the Content Transfer Applet for many years due to issues supporting Java versions on client machines as well as the inherent security problems with Applets. While the Webtop 6.8.2 version and higher removes the Applet, users are still required to install a browser extension as well as a native exe installation that utilizes Java.
This technical blog describes the installation steps and troubleshooting guide for Documentum Webtop Native Client plugin 16.4.
Recently at the client: a KPI dashboard is to be set up. We are currently conducting an initial discussion, presenting existing solutions and the software. A dialogue develops, first about technical content, then about the functions of the software, which very often leads to a question: “We can make changes ourselves and create graphics, can’t we?” Hmmmmm. Yes and no. Moreover, very important: “In any case we have to be able to load data from Excel, is that possible?” Yes… theoretically, yes. Then comes the next classic: “Besides, the processes in the IT department take too long, we can’t wait weeks for new KPIs to be visualized.”