This is the fourth post of my series „Insights into the development of migration-center 4“. In the last post I showed you how to configure and run a scanner in order to read all the desired files and their metadata from the source system. In today’s post I will show you how to organize your scan runs into so called migration sets. All further processing in the migration-center, i.e. transformation, validation and import will be based on a migration set. So the definition of a migration set is an important step in the whole migration workflow.
When you press the Organize icon in the main navigation bar, the client shows you the list of existing migration sets. You can use the icons in the command bar above the list to create, edit, copy or delete a migration set.
Die Digitalisierung verändert die Welt nachhaltig. Neue digitale Technologien drängen mit immer höherer Geschwindigkeit auf den Markt und ermöglichen eine Vielzahl von neuen Geschäftsmodellen. Netflix und Co. haben die Videotheken eliminiert, Uber setzt die Taxi-Industrie unter Druck, die Hotellerie spürt den Atem von Airbnb im Nacken und die Autoindustrie fürchtet sich vor Tesla, Google, Apple und Co mehr als vor den üblichen und bekannten Wettbewerbern.
Sometimes not the leading edge technologies are causing you headaches, but also solid requirements like synchronizing your Document object’s attributes with SAP.
In this blog post I will explain the differences and purposes of the OpenText Documentum Archive Services for SAP and OpenText Documentum Content Services for SAP as well as the challenge to synchronize only modified SAP data into OpenText Documentum.
OpenText Documentum Archive Services for SAP
The main purpose of the OpenText Documentum Archive Services for SAP (ASSAP) is to accept content (e.g. the printable bill) delivered by SAP. For this, the ASSAP exposes as ArchiveLink server. With the ArchiveLink protocol, SAP is not only able to archive content but also able to retrieve that content for display purposes. Such content can be for example billing documents. So the active part is SAP. OpenText Documentum is the passive part. The ASSAP will create the link information with SAP archive maintenance data.
The continuously growing number of contracts and their precise handling is a constant challenge to many organizations. Therefore, fme developed an OpenText Documentum D2 based Contract Management Framework. With this framework, clients can efficiently manage their contracts and ensure that they are accurately recorded and audited to meet compliance guidelines. But what’s behind all this? Let’s take a closer look!
OpenText Documentum D2 – a solid backbone
The OpenText D2 background provides a configurable and adaptable basis with which the contract management solution can easily be adapted to customer needs.
Main functions of the fme D2 Contract Management Framework
The solution contains all basic settings for the setup of contract management documents and processes: a set of document types with attributes, lifecycles and workflows, permission control and search and reporting functionality.
Additionally it contains a specific clause library functionally to compose contracts of already reviewed and internally approved text blocks, which are organized as part documents and serve as contract template parts. This reduces risks of inconsistency and ensures organizational compliance.
(German version below)
In my last blog post, ‘Digital Transformation Is About More than Just IT,’ I wrote about a fortunate trend, whereby more and more companies are taking a more holistic approach to the digital transformation. We know that IT alone is not the solution to the challenges posed by the digital transformation. More and more companies are slowly realizing that the digital transformation affects not only the IT department but also all other areas of the company.
But training courses and consulting services that are currently being offered give a different impression. Discussions revolving around the digital transformation primarily address the challenges in today’s business world, and terms such as ‘agility’ and ‘new business models’ crop up as the important key terms. Well-known companies that were once successful are mentioned as examples of organizations that did not manage to get on the right path towards digitalization. The training courses and consulting services then frequently put forward new IT procedures and technologies – such as cloud computing, microservices, DevOps, and big data – as solutions to the challenges of our time. However, IT departments are often not trusted to successfully introduce such modern solutions.
IBM Notes has been around for so many years – yet still many companies use it. Some are heavily relying on it as it supports many different processes – it can be used as an email tool for communication, as a database with or without any kind of documents and even as a feature rich application for (critical) business processes and workflows.
Notes is flexible and supports all kinds of different and custom scenarios.
However, there are several reasons to replace it with other platforms, especially when it comes down to document management. I do not want to talk about them in detail because you might know those already and therefore are reading this right now.
I want to talk about the solution to move to other platforms and I want to clear up doubts about the possibility to lose any information during the migration.
The typical migration scenario with migration-center is to read – or scan, as we call it – documents and their metadata from the source system (1), do necessary transformations on those documents in order to fit the target system (2), and finally write – or import – them into the target system (3).
(English version below)
Mit Sicherheit haben auch Sie bereits davon gehört, dass immer mehr Unternehmen Software einsetzen, um die interne Kommunikation, Zusammenarbeit in Projekten oder auch das Onboarding zu verbessern. Ausgangssituation ist oft ein älteres, unmodernes Intranet, welches von den folgenden Problemen betroffen sein könnte:
- Unübersichtliche Struktur (z. B. zu viele Gruppen, unsortierte Beiträge)
- Wenig Aktivität
- Schlechte Bedienbarkeit
- Unzufriedenstellende Funktionalität
Heutige Unternehmen wenden sich deshalb oftmals von diesen statischen Systemen ab und suchen nach Lösungen, welche besonders den Mitarbeiter in den Mittelpunkt stellen – und nicht die riesigen Datensammlungen, so wie man sie häufig in älteren Intranets findet.
Migration is an ongoing IT topic and there are many good reasons for that: Switching platforms or architecture e.g. when changing an operating system or database, virtualization and moving to the cloud are some reasons to be considered. In addition, the integration or merger of systems and applications can make content migration a relevant topic, as cost efficiency is a big deal in these cases.
Are you currently facing a migration project? Especially any Documentum migration task? Have your colleagues given you any serious advice to handle Documentum object IDs very carefully? A common example for that: Published links in intranet or e-mails referencing important documents through object IDs. Have you been asked to keep these documents’ object IDs and all their links working?
In this blog post I want to share some thoughts, experiences and solutions on migration regarding Documentum object ID concerns with you.
Despite the ongoing discussion about the prospects of new web technologies, progressive clients or even the need of an unmitigated new user experience, many enterprises are still using the “good old Documentum Webtop” quite contentedly. In general, Webtop applications integrate smoothly with other systems that have spawned over time such as Jive, Jira, CRM and others.
Nevertheless, let’s be honest. There have been some flaws and one of them has always been the content transfer mechanism UCF which can be hard to maintain especially in complex network settings and which causes an annoying dependency on the client’s Java Runtime Environment. With modern browser vendors reducing plugin support and the decision of Oracle to deprecate the Java browser plugin in Java 9, a new content transfer mechanism was long overdue.