User Forum Brings Life Sciences Community Together

User Forum Brings Life Sciences Community Together

by | May 2, 2019 | Documentum, ECM, Life Sciences, OpenText

The meeting held in April brought together business and technical leaders from within regulatory affairs, quality, and IT to share their experiences with regulatory content management strategies, technology implementation challenges, and leveraging next-generation digital tools to automate and improve business processes.

The meeting held in April brought together business and technical leaders from within regulatory affairs, quality, and IT to share their experiences with regulatory content management strategies, technology implementation challenges, and leveraging next-generation digital tools to automate and improve business processes.

To garner deeper perspectives and insights, attendees separated into three groups and were asked to discuss three key topics:

  • Priorities and considerations when deploying an end-to-end regulatory information management (RIM) solution, including technical priorities, platform limitations, and the limitations posed by document and data quality.
  • Upgrading and re-platforming to OpenText Documentum for Life Sciences, taking into account master data management, goals to streamline processes, and compliance or data quality issues that should be improved.
  • Quality management solutions, sharing current experiences and areas that need improvement, managing change control processes, and existing measures to oversee QMS processes.

    • The post discussion roundtable resulted in a healthy and productive exchange of ideas and experiences. These perspectives will be further explored in future LSUF meetings.

    A Focus on Improving Processes

    The effort to improve and simplify processes is a high priority for life sciences companies. Artificial intelligence offers a powerful opportunity to improve document quality, for example by enriching metadata. During the meeting, fme talked about the intelligent document classification and metadata enrichment solution it is developing in partnership with Docxonomy, called fmeMATRIX. As establishment of the solution continues, the views and experiences of clients will be integral to applying a progressive approach. The LSUF meeting was a key opportunity to garner feedback on the needs and concerns of life sciences companies.

    Here are some additional takeaways:

    • In another LSUF presentation, one of our clients shared its experiences with collaborative authoring, using technology to enable simultaneous or parallel authoring and review in real-time. Integral to enabling the company to meet its regulatory requirements is SharePoint Connector, and the client team is working with OpenText on implementing this capability.
    • During its presentation, the client’s IT account manager and IT regulatory architect posed several key discussion points and questions for their peers. These included how other companies tackle collaborative authoring of submissions and the point at which a document becomes an official record, based on good practice guidelines.
    • During another presentation, a client presented a proven, iterative approach to integrate a leading Regulatory Information Management platform into the OpenText Documentum for Life Sciences Research and Development module. The client outlined an approach that ensured quicker solution implementation timelines and more effective R&D alignment and buy-in.

    These were some of the highlights from the April LSUF meeting, which was the second forum meeting to bring together the life sciences client community to exchange ideas. The next forum will be held this October and we look forward to further productive and insightful discussions. Please reach out to me if you’re interested in joining this growing group!

    Why OpenText Documentum products and Cloud Computing are complementary!

    Why OpenText Documentum products and Cloud Computing are complementary!

    by | Aug 17, 2018 | Documentum, ECM, Life Sciences, OpenText

    Compared with cloud computing technologies that are very strong in providing elastic (scalable) services OpenText Documentum products could be regarded as inflexible and monolithic / layered applications. Although they seem to be the exact opposite of the flexible Microservice architecture approach used for cloud native application design, there are ways to combine OpenText Documentum products with cloud computing technologies.

    Here are some examples to give you an idea of how to achieve more flexibility by breaking either the OpenText Documentum base installation or business logic into smaller services.

    Infrastructure Services

    A classic OpenText Documentum Content Server installation could be split into four services / Linux containers:

    • The Docbroker
    • The repository services
    • The Java Method Server (serverapps.ear)
    • The Accelerated Content Services (acs.ear)

    It is obvious that the Docbroker does not have to deal with much traffic and does not need any load balancing. Thus one or two instances at most could be sufficient (complemented with according health check monitoring) to provide a robust fail over.

    For the repository services, the Java Method Server and the Accelerated Content Services, two instances each are sufficient to provide a quite robust service.

    However, at some point you might want to perform a data migration into your repository with many documents for example. In this situation, you might think of hiring our highly skilled content migration team. During the migration period, especially with systems utilizing the Java Method Server heavily, exactly this service would become a bottleneck. All other server components would be able to handle all migration tasks.

    And here things become interesting: If you had used the service architecture as described earlier and you had been utilizing an orchestration tool, you would have been able to request two additional Java Method Server instances on-demand within minutes. The orchestration tool automatically creates two more instances, which are automatically proxied via a service end point. All upcoming migration requests are then spread over all existing instances, providing a good migration experience. Once the migration is finished, you can scale down the number of instances.

    Business Logic Services

    If you are using OpenText Documentum D2 e.g. and have potentially “heavyweight” logical services like watermarking, you can create real services (Microservices) and connect them to service discovery tools with load balancing/fail over aware clients (e.g. the Netflix OSS – Eureka, Ribbon, Hystrix). With this option, the watermarking service becomes scalable and flexible for any upcoming future needs and can be placed or moved to dedicated computing resources as needed. If at a certain point this service is identified as a bottleneck, you may instruct your orchestration tool to create additional instances of the same service. If there is a one-time event like a submission to an authority, you may also instruct your orchestration tool to create additional instances of the same service, but you are able to downscale the service after the specific event has finished in order to efficiently use your hardware resources.

    Conclusion

    Do not fear to use the best of both worlds! We will support you in combining both technologies and providing best results to you!

    • Analyze your existing OpenText Documentum infrastructure architecture
    • Analyze your existing OpenText Documentum software architecture
    • Create a roadmap with you on how to make your OpenText Documentum stack cloud computing-ready
    • Create best practices on how to create future components inside your existing OpenText Documentum stack to make them elastic and to comply with the concepts of cloud computing
    • Move application logic (where applicable) into elastic Microservices

    We are looking forward to sharing our expertise with you!

    Traditional or cloud-native? Why not something in between?

    Traditional or cloud-native? Why not something in between?

    by | Aug 9, 2018 | Documentum, ECM, OpenText

    Your on-premise cloud options at a glance

    Starting from complete use in their own data center (on-premise), companies have the following options:

    1. Cloud storage: adding storage capacity from the cloud to your application.
    2. Re-platforming
      1. Lift’n’Shift: i.e. virtualizing or containerizing the application and hosting the virtual machines or containers with a cloud provider. Of course, provided that the containers are orchestrated accordingly, they can also be hosted in one’ s own data center.
      2. Lift’n’Extend: i.e. to containerize the applications and to enhance with other cloud services functionally, or to create new cloud-native functions. It is also possible to develop individual elements of the application, e.g. the clients, in a new and cloud-native way and to link them to the backend. Such solutions are commonly referred to as hybrid cloud applications; not to be confused with hybrid cloud concepts.
    3. Re-Factoring: i.e. to redevelop the application on a PaaS stack as a cloud-native application. If the solution is based on a commercial basic product such as a DMS that is not cloud-compatible, this method is not possible.
    4. Use a new solution from a SaaS provider.

    Containerization as an ideal middle way between traditional and cloud-native

    For example many organizations, are facing the decision to continue to operate DMS-based solutions at great expense and cost or to choose option 4, i.e. to switch to a SaaS provider. However, the options listed under 2 offer an ideal middle way with containerisation.

    The advantages of containerization have already been described in detail in the fme blog post “How can Linux containers save your day?”.
    Our “Distributed Environments With Containers” data sheet provides a more technical insight into containers. In particular, the use of containers in validated environments – so critical for the life sciences industry – is a prime example of the additional advantages offered by container technologies.

    Your container advantages at a glance

    • Proven software and aplications remain in use
    • The user interface and user guidance remain the same
    • Faster, less error-prone, automated processes can result in faster application deployment and lower validation costs
    • The agility in projects increases
    • Upgrade paths are simplified: Entire migration environments are containerized, even with different host operating systems for which previously elaborately installed, own virtual machines were necessary
    • The applications are manifold!

    Strong expertise from fme’s independent cloud, container and migration experts

    The containerisation experts from fme disassemble the basic product, pack it into containers and reassemble it in your data centre or at a cloud provider, such as AWS, to form the new basic application. For some products, fme has already built ready-to-use containers that can be rolled out fast and easily. Subsequently, configurations and, if available, customizations are made. The new system is filled with the fme Migration Services and thus a 1:1 copy is created. What sounds so simple requires a high level of expertise and is associated with costs that are more than justified if one considers the advantages of containerization.

    A useful example for Lift’n’Extend (2b): Connection of Alexa to a containerized DMS application

    An example for the extension of a containerized DMS application with native cloud services can be seen impressively in the YouTube video Showcase: Alexa, please open Documentum! “ For this purpose, fme containerization experts have rolled out OpenText Documentum on AWS and fme AWS specialists have connected it to Alexa. We believe that Alexa skills can make your daily work easier. In environments where operating a system with mouse and keyboard is difficult, Alexa can use voice commands to find and read documents. A use case could be a laboratory where safety gloves have to be worn, but the user working there needs SOPs from a DMS system.

    The OpenText Documentum REST API? – A field report from the developer’s point of view

    The OpenText Documentum REST API? – A field report from the developer’s point of view

    by | Aug 2, 2018 | Documentum, ECM, Inside fme, OpenText

    What is the “Documentum Rest API”?

    In principle, the term Documentum REST API refers to a web interface introduced with Documentum 7 that allows access to objects and functions of OpenText Documentum. This is based on Spring-Boot, is delivered as a WAR file and must be installed on an application server – e.g. Apache Tomcat. This interface can be used to write customized clients, apps, or plug-ins of other systems.

    Before the Documentum Rest API, the APIs DFS and DFC had to be used as an interface for business applications in order to interact with Documentum. DFS is based on SOAP and is therefore also a web interface, while DFC is based on Java.

    The REST API consists of several residual web services that interact with OpenText Documentum. It is “hypertext-driven, server-side stateless, and content negotiable, which provides you with high efficiency, simplicity, and makes all services easy to consume” [Source: https://community.emc.com/docs/DOC-32266, date of collection: 29.11.2016 – 11:51]
    Introduction to REST Services

    To understand how the Documentum REST API works, the first step is to explain the basic operation of a general REST service. REST stands for Representational State Transfer and is based on a stateless, client-server and cache capable communication protocol. In almost all cases the http protocol is used. REST is additionally hypertext controlled, i.e. REST clients must have all the information they need at any given moment to decide where to forward them. Hypermedia connects resources and describes their capabilities in a machine-readable way. For this reason, a REST client only needs to know one thing to communicate with the REST server – the understanding of hypermedia.

    REST itself is an architecture style for network services (web services), where complex mechanisms should be avoided as far as possible by using simple http calls.
    This means that a REST web service and its functions can be called without much effort from a simple http client. A call via the browser – which is also based on an http client – is also possible if the web service has implemented a GET call for the specified service URL. It is because of the http protocol that the functions and accessibility of the REST services can be easily tested and used, for example, for the in-house development of a client whose code base can be determined by the user.

    In addition, the REST API can be accessed from any client, provided that this client is on the same network and can authenticate and authorize itself. An installation of local software is not necessary for the accessibility – for the use of the functions only an http-Client must exist (e.g. browser or self-developed client).

    Compared to SOAP, REST also offers a small performance advantage..

    Functions of the services

    The Documentum REST API is delivered with some REST services that allow you to call basic functions of Documentum. Here is a brief list of what I think are the most interesting services:
    Object Service
    This service allows interaction with Documentum objects inheriting from dm_sysobject, such as cabinets, folders and documents. You can use the service to display objects, create and change new objects (for example, check-out/check-in, new rendition,…) or delete objects.
    Objects that do not inherit from dm_sysobject must be implemented through an extension of the REST API. Read more about this in the section Extensibility.

    User Service
    This service can be used to manage users, groups and ACLs. This means that user administration can also be accessed from an external source and easily adapted to your own processes and requirements.

    DQL Service
    The DQL web service is a service that allows you to execute DQL queries and report their results back to the client. By default, the DQL service only supports select queries for security reasons. Also for security reasons, changes to objects via DQL should be implemented using your own, secure services.

    Example Call of the Object Service
    Once the REST API has been successfully installed on an application server, provided the firewall rules have been set up correctly, it can be called by any client from the local network under the link “/dctm-rest” (example: http://vm-documentum-app-test:8080/dctm-rest for default Tomcat configuration). When calling up this URL, e.g. via the browser, you should then be able to see the following:

    If the above link, adapted to local conditions, cannot be called either via the network or locally from the application server, the log files must be inspected. Most likely something failed during the installation of the REST API.

    Clicking on the “Services” button would call “/dctm-rest/services” (example: http://vm-documentum-app-test:8080/dctm-rest/services).
    The result, when the page is called up, should look something like this:

    If you now call the first URL, for example, all Documentum repositories would be displayed:
    The URLs contained in the entries could now be used to connect to the repositories using valid logon data, for example to execute a DQL query, check out a document, or similar.
    Induction
    With the appropriate knowledge of the architecture and function of REST services, training is relatively quick, since the Documentum REST API corresponds to a REST-compliant interface. In addition, OpenText provides many helpful tutorials and code examples that can be found on the Internet. OpenTexts code libraries, which are available in almost all common programming languages (Java, C#, Pyton, Swift, Ruby, Objective-C, AngularJS,…) on GitHub, complete the simple introduction.
    Nevertheless, these GitHub libraries should be chosen with care, since you depend on the written code and the libraries can be adapted by the manufacturer at any time. Features could be different with a new patch and not work as before, which can lead to errors.
    The other option would be to create a custom written code library that accesses the API. This ensures independence from the code libraries provided by OpenText and gives you more control over what happens in the foreground during development.

    Extensibility
    As already indicated in the point of the individual functions of Documentum REST Services, not every function of Documentum is enabled via the web interface described here in the standard system.
    However, if functions that are urgently required for business logic are missing in the standard delivery of the REST API, they can be implemented using enhancements to the REST services. It should be noted that the familiarization is not quite as simple as, for example, for the initial entry of the creation of a document management client. However, thanks to the documentation of the REST API and good examples on the OpenText community page, most of the initial problems can be handled easily. It is implemented in Java and using the build management tool Apache Maven.

    Docker Support
    Since version 7.3, Documentum REST web services can officially be executed as a finished docker image in a Docker container. The support of Docker is in my opinion the right step to place the REST API as the primary web interface. Docker makes it easy to scale and migrate to other servers without much effort. For this reason, the finished REST API can be quickly integrated into the internal network and used, of course under the circumstances that the necessary Documentum infrastructure already exists.

    Summary
    Documentum REST web services offer a good and beginner-friendly way to interact with OpenText Documentum from self-implemented systems or clients. In my opinion, the quick training in the functionality and use of the API is especially positive. But you should be careful with special cases, because the implementation of an extension of the standard API is a time-consuming process and requires some training. The possibility of using the services from all possible programming languages and thus also with any operating system is also very nice.

    20 Years Partnership Anniversary Documentum and fme – And still going strong!

    20 Years Partnership Anniversary Documentum and fme – And still going strong!

    by | Jun 27, 2018 | Documentum, ECM, Inside fme, OpenText

    At fme we are proud that this year marks the 20th anniversary of our partnership with Documentum, now part of OpenText. It is a success story with countless successful client projects, a world-renowned product that has been certified for more than 10 years, extensive platform and industry-specific process know-how and a great team of highly specialized employees.

    When we started our first Documentum project in 1998 together with an automotive client, Enterprise Content Management was just one flourishing plant in fme’s portfolio at that time. Today, 20 years later, this area of our portfolio builds a solid cornerstone of our corporate strategy and is one of the reasons why the small team of around 15 employees at that time has grown into an international group of companies with more than 230 employees and locations in Germany, Romania and the USA. Our clients trust in Documentum: We still work with the client from back then and the installation we support has grown to be one of the largest with more than 70 thousand users and is the client’s only platform approved for confidential and secret documents. Of course we have gained many more since then, some of which we are supporting in projects around the globe with the help of fme SRL (founded in 2005) and fme US, LLC founded in 2010.

    Long-term Solutions Based on OpenText Documentum

    One of the most told anecdotes around our ECM Business is the following, and it somehow fits perfectly to our anniversary, although the client decided to go with a different platform in the end:

    Way back we were having a Document Management workshop with one of our earliest clients, a regional church nearby. We talked about storage media reliability:
    Consultant: “Well, hard disc storage has to be reorganized every 3-5 years to avoid data loss caused by hardware failure. You better use CD-ROM storage which will keep your data safe for some 15 years.”
    Client: “At our church we do not store for 10-15 years… WE ARCHIVE FOR ETERNITY!”

    Our expertise in long-term archiving has grown since then and one of our most reused solutions is the historical company archive based on Documentum which we have set up for large corporations like Volkswagen, Telekom, and the Deutsche Post DHL. More and more clients also trust in our Documentum Application Management Services (AMS) and work together with our skilled Team in Cluj, Romania.


    Memorabilia of one of our consultants looking back to 20 years software development with Documentum

    Supporting Documentum, EMC’s Enterprise Content Division, DELL EMC and now OpenText

    In the past 20 years Documentum was subject to some mergers and acquisitions but the community is still alive. OpenText acquired the Enterprise Content Division of EMC in 2016. Many clients initially seemed to be uneasy about the future of Documentum but we were and are sure that OpenText Documentum is here to stay. Please see Dirk Bode’s blog post “Keep calm and love Documentum (at least quite a bit longer)” and the interview from OpenText Enterprise World 2017: OpenText Live Presents Dirk Bode, fme AG on consulting – YouTube if you are interested to learn why. The messages from OpenText during the last two years are clear: they are committed to further developing Documentum as it has proven to be a reliable and scalable platform that continuously adapts to an increasing number of requirements and the clients have resumed their projects. We are excited to learn more about the latest news at OpenText Enterprise World in Toronto in July.

    Growing Documentum Expertise

    We are happy that continously training our experts on the latest trends and requirements of our clients has proven to be the right decision. Over time we have added industry-specific process expertise which means our industry experts are both Documentum experts AND for instance Certified Regulatory Document Management Compliance Professionals. To fulfill the high demand for certified Documentum experts we are also regularly hiring additional team members. Should you be expanding or reorganizing the strategy for your OpenText Documentum platform majorly please talk to us so we can align our services and resorces even better to your requirements. Last year we set up a showcase with OpenText Documentum and Amazon Alexa to demonstrate how Documentum can be managed via voice control. Such innovative solutions are of course based on our team’s deep core knowledge with Documentum. Fun fact: did you know that we are using Documentum internally at fme group? One of the most useful customizations we did is the document number – our corporate presentation is probably the best known document number: everybody knows the #6120 😉 Combined with the extended search you can find documents very fast and easily using #… when searching for numbers, *… for document names, and +… for folder names.

    Constant Active Member of the Documentum Community Since 1998

    Our commitment to the Documentum platform is obvious: numerous client projects, annual exhibition appearances at all OpenText events, a longterm membership in the Documentum Partner Advisory Board and many marketing campaigns prove this. With the organization of the OpenText Documentum User Group in Germany and in the United State we help our clients connect and benefit from the OpenText Documentum community. Last but not least many awards over the last years demonstrate our commitment. This year we have been nominated as one of three candidates for the OpenText PARTNER of the Year Award in FY 2018. The winner will be announced during the Enterprise World Partner Session on July 9th. Keep your fingers crossed for us!

     

    fme and OpenText Documentum History 

    Important milestones in 20 years partnership between Documentum and fme

    We believe in Documentum and look forward to continuing this story with you, as our clients and partners and of course with you, our employees! Cheers to the next successful 20 years with OpenText Documentum!

    Landingpage 20 Years Anniversary Documentum & fme with videos

    Digitalization? I can’t hear it anymore!?!

    Digitalization? I can’t hear it anymore!?!

    by | Mar 29, 2018 | Documentum, Life Sciences, OpenText

    A spokesperson for the association even apologizes for addressing the subject of digitalization at all. Of course, there is often not much fundamentally new knowledge about digitalization in general to gain in lectures and seminars when you have already attended numerous lectures, visited Silicon Valley, admire Israeli startups and experience Asian digital power. I even believe that in many cases the top level management has largely understood the topic – it is most certainly high time for that.

    However, digitalizationis not a phenomenon that is solved at boardrooms with an army of assistants and “SWAT teams”. The general consensus is that the challenge can only be met successfully if all of a company’s talents are gradually taken on a journey into the digital future. The corporate culture – here too there is agreement – is the key to success in the digital world. Companies need more speed, agility, creativity, innovation, experimentation and networking in order to successfully face the digital “> VUCA world“.

    It is in fact unfavorable if the entrepreneurial leadership is already annoyed as soon as the subject of digitalization is discussed here and there.

    The digital experience of revival or “when the penny drops”

    Even the most experienced digitizer had his personal awakening experience at some point – the moment when the penny dropped, when everything came together; the moment when it became clear: Something really big is happening and I know where it is coming from, why it is happening, what effects it has and how we can react to it. Exactly this experience is what every employee in the company needs – of course this is also possible without a trip to Silicon Valley, Israel or China – we are happy to help you 😉

    Only if all forces in the company understand the risks and the incredible opportunities of digitalization can they pull together in the long term. Even today, stories of UBER, Netflix, Airbnb and Amazon or pictures of the papal election in the past and today still help.

    So the next time the topic of digitalization comes up, or one of the well-known examples is attempted, then just remember that perhaps the person next to you is having his or her personal digital revival experience and refrain from the usual sayings like “do I already know, can I already, I was there already”. Even with many entrepreneurs the penny has not yet fallen – do not spoil the moment for them, but rather help them to understand the topic by new examples and pictures. Or use the time when things repeat themselves to develop concrete ideas and measures on how you will take your entire company on the digital journey.

    Become a patient digitalization ambassador

    Don’t let digitalization get on your nerves, but become a patient ambassador who constantly explains and explains why digitalization is at the same time the greatest challenge and opportunity for every company since the industrial revolution. Of course, concrete implementation is a prerequisite for success in the end, but without employees who have understood what it is all about and who have understood the opportunities that lie dormant in the topic, implementation will not succeed.