AssetWise to OpenText PoC Closeout Report

Transcription

1 AssetWise to OpenText PoC Closeout Report Page 1 of 8

2 AssetWise Interoperability Architecture 1. References Glossary Revision History Introduction and Overview Objectives Architecture Physical Architecture PoC Scenarios / Scope of Work Outcomes Deployment Alternatives SharePoint AssetWise Only... 8 Page 2 of 8

3 1. References Number Description B Design Description - 2. Glossary Term Description ECM Bentley AssetWise and ProjectWise Enterprise Content Management Capabilities LOB Line of Business Applications ODATA Open Data Protocol WSG Bentley Web Services Gateway BECS Bentley Enterprise Connection Services WCF Windows Communication Foundation REST Representational state transfer CCOM MIMOSA CCOM - Common Collaborative Object Model 3. Revision History Date Description Person Nov 9, 2016 Initial Draft Hilmar Retief Page 3 of 8

4 4. Introduction and Overview Starting in 2015, Bentley embarked on an effort to demonstrate how MIMOSA ISBM could be used to interoperate between Bentley s AssetWise CONNECT and a locally deployed SAP instance. The information exchanged during this PoC were asset and tag based, but did not include any documents exchange. Following this successful effort, Bentley supported an additional PoC, this time showing how documents, including its metadata, originating from AssetWise CONNECT, can be published to an OpenText instance, hosted in Azure. This project commenced on September 12 th 2016 and concluded in early October 2016, with a demonstration to stakeholders, illustrating a successful transfer of files and metadata, per predetermined and agreed upon uses cases. 5. Objectives The main goals for the OpenText PoC were: a) Publish new and modified documents and their associated metadata from AssetWise CONNECT to an Azure hosted instance of OpenText. b) Publish a flag to OpenText for documents that were marked for change in AssetWise. c) Use out-of-box Bentley interoperability capabilities with relatively minor configurations to support OpenText connections. 6. Architecture The out-of-box AssetWise architecture that supports interoperability in general and this OpenText PoC in particular can be illustrated by showing two views. The first view shows the overall service oriented architecture of AssetWise where one of the service endpoints is responsible for interoperability: Page 4 of 8

5 Figure 1: Functional Services View The second view illustrates the use of the interoperability service in the context of a complete AssetWise CONNECT deployment; in this case a hosted deployment with connections to adjacent cloud infrastructures or on-premise applications: Figure 2: Logical Interoperability Architecture In Figure 2 the interoperability service is shown in the context of the Bentley service bus (BECS) deployment. BECS s role is to receive interoperability notifications and publish them to designated partner applications or receive notifications from interoperability partners and update AssetWise. Page 5 of 8

6 This workflow can best be illustrated by the following diagram showing the origination of a message, based on a business event such as a document approval, from AssetWise and then pushing that message through to OpenText (in this case) via the service bus (BECS): Figure 3: Outgoing Message Flow It should be clear from this diagram that all external connectivity is managed by BECS. This simply means there is no need for individual Bentley applications to directly talk to individual 3 rd party applications. This architecture supports scalability, ease of maintenance and controlling interoperability costs. 7. Physical Architecture Physically, the PoC infrastructure comprised of a Bentley hosted VM for AssetWise, a Bentley hosted VM for BECS and an Azure-based instance of OpenText. Connectivity among Bentley applications are as described above, while OpenText endpoints were made available as HTTPS/SOAP web services. All calls made to OpenText web services were performed by a BECS service account. The PoC did not address replication of security or authentication beyond the BECS service account needing access and permission to copy files and metadata into an OpenText location/document library. 8. PoC Scenarios / Scope of Work The following use cases were addressed under the contracted scope of work: Primary Use Cases (Required) o Add a file with associated metadata (AssetWise document attributes) to OpenText based on a document approval event in AssetWise. o Replace the same file and its metadata in OpenText based on the re-approval of the document in AssetWise after a revision was made. o Update a pre-configured property in OpenText showing that the file is under change, based on that document being placed on a planned/expedited/approved change request. Page 6 of 8

7 Extended Use Cases (Optional) o Add/update OpenText file metadata based on a document approval event in AssetWise with the equivalent attribute values as updated in AssetWise. o Provision URL s in AssetWise to enable users to navigate to the connected file in OpenText and vice versa. During the PoC demonstration all the required use cases were shown. Feedback provided during the demonstration was that all use cases were demonstrated successfully. 9. Outcomes The PoC was successful in demonstrated all required use cases. 10. Deployment Alternatives In addition to the OpenText scenarios discussed in the body of this document, there are additional options discussed here to facilitate similar outcomes as it relates to documentation associated SAP asset records. These options include using SharePoint instead of OpenText, but essentially continue to use the same architecture where SAP leverages SharePoint for documents associated with SAP asset records. The second option avoids using either OpenText or SharePoint for engineering documentation and instead associate Bentley AssetWise documents directly to SAP assets by populating a link table in SAP with assetdocument associations with AssetWise hyperlinks SharePoint Conceptually the AssetWise Interoperability Service interacts with SharePoint and OpenText in exactly the same way, namely AssetWise is connected to one of these two repository types via a BECS connector. The rest of the architecture and even the business workflows are identical. Having that context, the remaining questions are around using SharePoint Online, SharePoint Server and ultimately the impact of a customized SharePoint instance. SharePoint Online vs SharePoint Server While a detailed discussion on the differences between SharePoint Online and SharePoint Server is beyond the scope of this document, it suffices to say that the main difference is the location of the repository, namely hosted or on-premise. Interactions with either of these in terms of the API or web services do not change significantly. A significant aspect however is how authentication and authorization differs between the two. For SharePoint online, federated security is generally required and hence will need to be accommodated in such a design for interoperability as well. Page 7 of 8

8 As it pertains to a customized version of either of these, generally customizations such as adding web parts etc, doesn t change the way the API works and therefore should not realistically affect how interoperability works. Publishing Files vs Links The AssetWise Interoperability Service supports an option to publish the file itself or a link to the source repository. In the latter case, the user will experience this in SharePoint as a file icon in the document library. Upon clicking on the icon, the underlying hyperlink will take the user back to AssetWise where they will be re-authorized, as is the case with any hyperlink, and subsequently display the file or document, as configured AssetWise Only File References The second option for making documents available for SAP assets in the SAP user interface, is to publish and keep updated, a list of associated document links to the SAP asset. The list may contain any metadata deemed necessary, but will in addition contain a link back to the AssetWise document or file. Upon clicking on the link, the hyperlink will take the user back to AssetWise where they will be re-authorized, as is the case with any hyperlink, and subsequently display the file or document, as configured. Work Package Printing Assuming all documents are associated to a work package in SAP, similar to the asset links described earlier, and all documents reside in the AssetWise community, AssetWise Server Printing can be configured to perform all printing based on an instruction via a SAP user interface. In order to facilitate the collating of documents to be printed, AssetWise will need a footprint of the work package to reside in the AssetWise data model. This footprint will thus resemble the work package in SAP, especially in terms of document relationships to the work package. A print instruction or notification from SAP, conceptually via the AssetWise interoperability Service, will trigger a batch print instruction for the work package. SAP Versions As discussed before, the connection to SAP or any other 3 rd party application is abstracted through the BECS connectors. These BECS connectors are technology specific, meaning whether ERP or XI/PI, a connector will communicate with each per their exposed API. End of document Page 8 of 8