ARCHIBUS White Paper: ARCHIBUS – SAP...

ARCHIBUS White Paper:ARCHIBUS – SAP Integration

Over 4 million users prove it daily—saving their organizations over $100 billion annually

Contents1. ABSTRACT .............................................................................................................................. 1

2. BENEFITS ................................................................................................................................ 1

3. CONCEPTS ............................................................................................................................. 2

4. BACKGROUND DATA SYNCHRONIZATION ............................................................................... 2

5. WORKFLOW PROCESS INTEGRATION ...................................................................................... 4

6. DOCUMENTS ......................................................................................................................... 4

7. DATA INTEGRITY ...................................................................................................................... 5

8. DESIGN FOR FAILURE ............................................................................................................... 5

9. CONCLUSION ........................................................................................................................ 6

10. APPENDICES ......................................................................................................................... 7

10.1 ARCHIBUS Functionality ........................................................................................... 7

10.2 ARCHIBUS Connectors: Streamlining Integration .......................................................... 9

10.3 SAP Modules .......................................................................................................... 9

10.4 Web Services ........................................................................................................ 11

10.5 SAP Interface Components ...................................................................................... 12

10.6 ARCHIBUS Web Services ....................................................................................... 12

10.7 Best Practices ........................................................................................................ 13

11. REFERENCES ....................................................................................................................... 14

The #1 Solution for Real Estate, Infrastructure, and Facilities Management in the World


ARCHIBUS - SAP Integration

1

ARCHIBUS – SAP Integration

1. ABSTRACTThis white paper provides an overview of ARCHIBUS application integration with SAP R/3 and discusses the potential benefits of such an undertaking. The same principles can be applied to SAP ERP, successor of SAP R/3.

ARCHIBUS is the #1 provider of real estate, infrastructure and facilities management solutions in the world, with expenditures for ARCHIBUS-related products and services exceeding $1.7 billion (US). ARCHIBUS provides a central repository for all building-related and spatial data.

SAP provides the capability to manage financial, asset, and cost accounting information; it manages production operations and materials, personnel, plants, and archived documents. SAP is the world market leader in the ERP (Enterprise Resource Planning) systems market, with nearly 27% of market revenues (Gartner ranking, 2008).

Real estate, infrastructure, and facility professionals play a critically important role in driving down the total cost of occupancy, identifying underutilized capital trapped within their physical asset portfolio, and reallocating resources to help fund core organizational strategies as well as improve operational performance.

But to do so they need the right tools. Tools that are cost-effective, deploy quickly, and provide immediate results. And, more importantly, they need tools that plug right in to their existing ERP infrastructure and provide intuitive visualization of the physical asset cost structure.

Integrating ARCHIBUS with your corporate ERP system unites financial and core business data with graphic facilities and infrastructure information, and contributes value to processes in both the core business and the facilities operation of the organization.

This document is targeted towards ARCHIBUS system architects and application developers, to give insight into the considerations and the potential benefits of such an integration.

2. BENEFITSEach organization has its own needs and requirements when it comes to gathering and dispersing information. Regardless of the specifics of data being managed, there are always opportunities to optimize how the data is shared.

Business Advantages

Integrating ARCHIBUS with SAP can yield an attractive Return on Investment (ROI) achieved by:

• Streamlined processes and reduced data administration which drastically improve productivity.

• Integrated, up-to-date information that enables accurate reporting to internal departments or external third-parties,

The #1 Solution for Real Estate, Infrastructure, and Facilities Management in the World2

ARCHIBUS White Paper


on a need-to-know basis, such as government and security agencies.

• Improved management of the use, maintenance, depreciation, and ultimate disposition of physical assets to maximize their useful lives and help organizations avoid unnecessary capital expenditures.

• Faster access to a centralized database to support the overall business plan.

Technical Advantages

Integration with SAP complements these inherent ARCHIBUS features:

• An open system architecture that enables easy data exchange with other information repositories.

• Flexibility to quickly generate and easily modify reports without the need for programming expertise or expensive customization.

• Seamless integration between the database and native AutoCAD drawings, as changes are made to either floor plans or assets, ensuring accuracy when creating reports.

• Ability to extend information across the enterprise via ARCHIBUS Web Central.

3. CONCEPTSFor all data that are defined in SAP and which are also needed in ARCHIBUS, synchronization of data is required. Organizational structure and employee data are mostly defined in SAP and should be updated in ARCHIBUS. Cost information in SAP can be made available in ARCHIBUS to classify cost data. SAP supplier data can be synchronized to the ARCHIBUS database.

Data defined in ARCHIBUS can also be sent to SAP, for instance, to update building, employee and occupancy information. The location (building, floor, room as well as phone number) of an employee is defined in ARCHIBUS, which may be sent to SAP.

A business process workflow may include different parts implemented in both systems. One system can hand over control of the workflow to the other system.

Integration can be implemented in different ways, depending on functional requirements, budget and security constraints. Organizations can provide asynchronous data integration using the traditional method of pushing/pulling data to and from flat data files. A more robust solution is to set up Web Services to enable instant communication between both systems. This solution manages data integrity better and it may be the only way to provide the data for certain processes in a timely manner.

The #1 Solution for Real Estate, Infrastructure, and Facilities Management in the World Over 4 million users prove it daily—saving their organizations over $100 billion annually


3

4. BACKGROUND DATA SYNCHRONIZATIONARCHIBUS applications are mainly structured around building data, while SAP is structured around cost centers (and company codes). SAP will always require a company code to classify cost accounting. In ARCHIBUS, all activities relate primarily to building data.

ARCHIBUS requires a unique building code for each physical building. Somewhat surprisingly, SAP does not generally utilize unique building codes, creating the need for a mapping table between the SAP building + cost center identification and the unique ARCHIBUS building code.

ARCHIBUS has organizational data structured in three levels: business units, division and department levels. Employees are assigned to divisions and/or departments. In ARCHIBUS costs can also be assigned to a division and/or department.

The most obvious thing to do is to map the SAP company code to the ARCHIBUS business unit, since both are at the highest level. Organizational information in SAP from large organizations may have a more complex structure. Employees should have SAP levels that correspond to a division and department level in ARCHIBUS. In smaller organizations, or some parts of the organization, there may be only one organizational level.

In ARCHIBUS, additional tables can be created for cost assignment. For instance, before sending a request to SAP for a purchase order, the responsible manager may classify and assign the cost center or other SAP-specific information to a record in ARCHIBUS. These managers may not have direct access to SAP, but should be able to assign SAP-specific data to ARCHIBUS data.

Real-Time Processing

Synchronous “real-time” integration achieves a tight interface and bi-directional data synchronization between ARCHIBUS and SAP. In this context, the term “real-time” means that data is automatically synchronized between the two databases. If a record is inserted/updated in database A, the same asset record is also immediately inserted/updated in database B.

Caution should be taken when accessing the database directly. It is advisable to only access data with the appropriate API. This is most certainly the case with SAP, and in an increasing number of situations also with ARCHIBUS (Web Central core functionality).

Asynchronous/Batch Processing

If real-time integration is not required, updates can be scheduled on a regular basis. Typically, there is a daily synchronization and update. This approach requires less system resources and a significantly smaller effort to set up.

When data is synchronized between two systems, one system is the “owner” of the data. Updates of specific data are entered in ARCHIBUS or in SAP, never in both systems. If data is updated in the owner system, data will be synchronized and updated in the other system.

Figure 1—Push/Pull—Example: Building data changed in SAP will be available the next day in ARCHIBUS.




Changes can be implemented as batch updates using flat files, but Web Services can be used as well, which is more robust. In this case, the Web Services can function asynchronously, queuing up updates without the need for immediate feedback.

Important here is to report errors and failures. If the update fails, measures should be taken to retry the update later or to reschedule for the next day. Updates can also be triggered manually when a failure report is received.

In the previous diagram, ARCHIBUS requests updates from SAP (pull), calling a Web Service. SAP will respond with a list of all changed records. ARCHIBUS can also push data to SAP. SAP will respond with a confirmation or error message.

5. WORKFLOW PROCESS INTEGRATIONIntegration with SAP can also be integrated as a workflow step. For instance, during the workflow of a service desk request, a step can be to call an SAP Web Service to request a purchase order number. When the request is received and handled in SAP, SAP can call an ARCHIBUS Web Service to send the response. The data is updated in ARCHIBUS and the workflow can proceed.

If SAP receives invalid or incomplete information, an error message is sent to ARCHIBUS. The “pull” data in ARCHIBUS must be changed and the request for purchase order must be sent again with new data.

6. DOCUMENTSDocuments (Word, PDF, etc.) uploaded in one of the systems might be needed in the other system. SAP users may not have access rights to ARCHIBUS or ARCHIBUS users may not have access to SAP.

Documents created and stored in SAP or in ARCHIBUS can be made accessible to both systems. Accessing a document can be a simple link (URL) or security/access rights can be provided by using Web Services to retrieve the binary data.

Documents can also be transferred from one system to the other. Since ARCHIBUS Web Central stores documents in the database, a simple synchronization script cannot be used, but Web Services can handle transfer of binary data. Documents will be stored in both systems.

Figure 2—Workflow Process Integration example.

Figure 3—Document access through Web Services.

Figure 4—Document synchronization.



5

Documents can also be stored in a single repository, accessible from both systems. Many organizations handle documents in centralized document management systems (e.g.,FileNet, Documentum, SharePoint, Project Library, among others). ARCHIBUS users should have access to the document management system to upload and download files. Documents stored in ARCHIBUS can also be transferred to a document management system using a Web Service if provided. A detailed description of document management is beyond the scope of this paper.

7. DATA INTEGRITYData in the database should always respect the constraints of the database for integrity and consistency. Be sure to implement transaction management for updates. When an error occurs, the system should roll back to a consistent state. Reporting and retry procedures must be implemented to ensure that data exchange between two systems is performed if one of the systems is temporarily unavailable.

ARCHIBUS uses natural keys for primary keys. A meaningful key is easier to use and more significant than a numeric value, especially in reports. When possible, one should try to find good candidates for natural keys. For instance, the first part of the e-mail address can be used as the natural key for employees. Candidate keys must be mandatory and unique.

Data in SAP can be made inaccessible by blocking codes or a record can be flagged for deletion. Blocking codes are used to mark a record inaccessible for all or only one company. A block code can be defined by a validation date. Records can also be unblocked or released. One approach can be to extend the ARCHIBUS tables with extra fields for blocking codes and validation dates. Business logic can implement restrictions to retrieve lists of valid and accessible data. In most cases, it is better to handle the data accessibility in the data synchronization process.

To detect a data change in ARCHIBUS, one can implement a database trigger and time stamp to record all changes. Data may be changed by different applications. For instance, the employee data can be changed in ARCHIBUS Windows Client/Server or by using a Web Central view file. This is why it is advisable to use database triggers, rather than implement the flagging of data, in the business logic.

8. DESIGN FOR FAILUREDesign for failure and nothing will fail. Be a pessimist when designing architectures, by assuming things will fail. When integrating data from two different systems and infrastructures, make sure measurements are taken for when things go wrong. Problems that can occur, include:

• Network problems between two systems

• Time-out when calling a Web Service

Figure 5—Centralized document management system.




• Integrity and constraint failures when updating the database

• Remote system down, due to maintenance

• Remote system returning error message

• Unexpected error caused by remote system throwing an exception

• Security and firewall problems causing unpredictable connection failures

• Overload in batch processing

Solutions:

• Log all actions

• Make sure failures are reported; create daily reports; notify System Administrator

• Provide a ticketing system for users that detect remote connection problems

• Provide automatic retry procedures for batch processing

• Decouple components, when possible

• Implement asynchronous communication for heavy load transactions

• Implement transaction and rollback for updates that may cause integrity and consistency problems.

9. CONCLUSIONBy using Web Services, you can expose data and functionality to other systems. This facilitates the integration of systems such as ARCHIBUS with other corporate systems such as SAP R/3, which vastly increases the value of your information by being able to connect it to related HR, real estate, maintenance, energy/utility, billing or other data. This integration of data from all areas of your operations aids operational analysis and decision support. It provides a more complete picture of your processes so they can be streamlined for greater operational efficiency and an improved bottom line.

In the future, software will be using a more service-oriented architecture (SOA), based on Web Services. A mature rollout of SOA effectively defines the API of an entire organization. And helps redefine the organization itself as one with an eye on the future, and the technology strategy needed to make that future everything it can be for all stakeholders.



7

10. APPENDICES10.1 ARCHIBUS Functionality

Forward-looking organizations are constantly striving to reduce their total cost of occupancy, but they need the right tools to succeed. Tools that are cost-effective, deploy quickly, and provide immediate results. And, more importantly, they need tools that plug right in to their existing ERP infrastructure and provide intuitive visualization of the physical asset cost structure.

ARCHIBUS captures the full range of real estate, infrastructure, and facility costs – leases, utilities, maintenance, moves, security, and much more. As a result, ARCHIBUS provides visibility to the true total cost of occupancy.

Moreover, ARCHIBUS maps costs against location, division, department, and time. Within this context, ARCHIBUS can provide insight to what this spend means to the organization. ARCHIBUS can map costs to divisions, departments, or cost centers and indicate their true profitability. Or it can compare cost and space resources in the portfolio against the future requirements based on a strategic plan and illustrate any gaps between the plan and the existing situation.




ARCHIBUS provides a fully integrated suite of rapid-deployment “commercial off-the-shelf “ (COTS) applications. Each application can be deployed independently as dictated by immediate need, and new functions and processes can be implemented once initial results are realized.

Many of the ARCHIBUS applications listed below are good candidates to integrate information with SAP. Information defined in ARCHIBUS can be sent to SAP or, alternatively, information from SAP can be retrieved to implement functionalities in the following ARCHIBUS applications:

• Portfolio Management

• Lease Administration

• Cost Administration

• Cost Chargeback & Invoicing

• Portfolio Forecasting

• US Federal Property Registry

• Capital Budgeting

• Project Management

• Space Inventory & Performance

• Personnel & Occupancy

• Space Chargeback

• Strategic Master Planning

• Enterprise Move Management

SAP financial data can be combined with ARCHIBUS graphical data and drawings. Visualizing information on drawings in ARCHIBUS will deliver added value. Some options:

• ARCHIBUS property and lease information can be integrated with SAP Real Estate.

• Personnel costs in SAP can be linked to ARCHIBUS occupancy data (Personnel & Occupancy).

• Costs created in ARCHIBUS Service Desk, On Demand Work and Preventive Maintenance can be linked to SAP cost and profit centers.

• Purchase orders can be created in SAP Materials Management (MM).

• Costs created in ARCHIBUS Project Management, Enterprise Move Management, and Reservations can be linked to SAP cost data.

• ARCHIBUS Asset Portal can be linked to SAP Plant Maintenance to manage equipment data.

• Asset Portal

• Furniture & Equipment Management

• Telecommunications & Cable Management

• On Demand Work

• Preventive Maintenance

• Condition Assessment

• Service Desk

• Reservations

• Hoteling

• Fleet Management

• Emergency Preparedness

• Energy Management

• Environmental Sustainability Assessment



9

10.2 ARCHIBUS Connectors: Streamlining Integration

To aid ARCHIBUS/SAP integration, ARCHIBUS has bundled its high-end ERP integration tool—ARCHIBUS Connectors—as part of its core product offering.

ARCHIBUS Connectors allow organizations to reuse information that already exists in their “gold-standard” data sources. The Connectors enable sharing of ARCHIBUS data with their SAP implementation, as well as with their Microsoft, Oracle, Sage, UFIDA, and other enterprise systems.

ARCHIBUS Connectors can also make possible rapid integration using industry standard transfer formats, such as OSCRE and COBIE.

ARCHIBUS Connectors can, for example, reuse personnel data from Human Resources systems for occupancy, hoteling, security, moves, and more. They can synchronize work processes with the most up-to-date account codes, or upload customer real estate billings and cross-charges from ARCHIBUS directly to the general ledger.

Other uses of ARCHIBUS Connectors might include supporting the adoption of Building Information Modeling (BIM) throughout an organization. Incorporating and integrating all the information about a property—from its initial design, to commissioning, to operational processes and much more—better informs stakeholders and improves decision support throughout a property’s entire lifecycle.

10.3 SAP Modules

Note that the following modules are SAP R/3 modules. SAP R/3 has been replaced by a newer version SAP ERP with similar modules. At the time of this writing, SAP R/3 is more widespread. Typically, you will find specialists in each module of SAP. Modules FI, CO, HR, MM and PM are often used to exchange data.

SAP FI Module: where FI means Financial Accounting – essentially this SAP module delivers your regulatory “books of record”, including:

• General ledger

• Book close

• Tax

• Accounts receivable

SAP CO Module: the CO stands for Controlling. Basically, this is the SAP Module which allows you to manage your internal cost/management accounting, including:

• Cost elements

• Cost centers

• Profit centers

CO relates closely to the FI module and often the term FI-CO is used.

Cost Center Accounting provides information on the costs incurred by your organization. Within SAP, you have the ability to assign Cost Centers to departments and/or Managers responsible for certain areas of the

• Internal orders

• Activity-based costing

• Product costing




business as well as functional areas within your organization. Cost Centers can be created for such functional areas as Marketing, Purchasing, Human Resources, Finance, Facilities, Information Systems, Administrative Support, Legal, Shipping/Receiving, or even Quality.

Some of the benefits of Cost Center Accounting: (1) Managers can set Budget/Cost Center targets; (2) Cost Center visibility of functional departments/areas of your organization; (3) Financial Planning; (4) Availability of Cost Allocation methods; and (5) Assessments/Distribution of costs to other cost objects.

Profit Center Accounting provides visibility of an organization’s profit and losses by profit center. The methods which can be utilized for ECPCA (Profit Center Accounting) are period accounting or by the cost-of-sales approach. Profit Centers can be set up to identify product lines, divisions, geographical regions, offices, or production sites, or by functions. Profit Centers are used for Internal Control purposes enabling management to review areas of responsibility within their organizations.

The difference between a Cost Center and a Profit Center is that the Cost Center represents individual costs incurred during a given period and Profit Centers contain the balances of costs and revenues.

SAP PS Module: PS stands for Project Systems, where you can manage your projects, large and small, including:

• Make to order

• Plant shutdowns (as a project)

• Third-party billing (overlaid to a project)

SAP HR Module: the HR is for Human Resources, where people are the important part of this SAP module, including:

• Employment history

• Payroll

• Training

• Career management

• Succession planning

SAP PM Module: PM stands for Plant Maintenance – where you maintain your equipment (e.g., a machine, an oil rig, an aircraft, etc.), including:

• Labor

• Material

• Downtime and outages



11

SAP MM Module: one of the most important SAP Modules, where MM is Materials Management, that underpins the supply chain, including:

• Requisitions

• Purchase orders

• Goods receipts

• Accounts payable

SAP QM Module: Quality Management – improves the quality of your goods, including:

• Planning

• Execution

• Inspections

• Certificates

SAP PP Module: one of the most important SAP modules is Production Planning – to manage your production process, including:

• Capacity planning

• Master production scheduling

• Material requirements planning

• Shop floor

SAP SD Module: another one of the large SAP modules is Sales and Distribution, from order to delivery, including:

• Request for Quotation (RFQ)

• Sales orders

• Pricing

SAP BW Module: BW stands for Business (Data) Warehouse, which includes the following main functions:

• Data extraction from source systems

• Some technical and functional transformation of the data

• Storage of the data in what are called Info providers

• Reporting (which uses Info providers)

• Inventory management

• Bill of Materials (BOMs)

• Master raw materials, finished goods, etc.

• Picking (and other warehouse processes)

• Packing

• Shipping.




10.4 Web Services

A Web Service uses a Web-based communication protocol called SOAP (Simple Object Access Protocol). In principal, SOAP data is sent over the network as an XML-formatted message.

A Web Service provides a means to call a function on a remote system. One system can send a request to another system and expect a response. Web Services provide an API to a remote system. Like any other function call, it may require some input parameters and have an output parameter. Both parties can provide WSDL files as a mean to describe the interface to the other system.

The Web Service definition is described by an XML file, called the WSDL file (Web Services Description Language). The WSDL file defines the method, input parameters, data structures and formatting, and the endpoint remote address that must be used to call the Web Service.

Web Services can be secured by authentication methods and using secure connections (https).

Use of these asynchronous calls can be required, because a user action is needed on the remote system, or the remote system uses a queue system for handling calls, or the risk of timeout can be too high and “hang” or block the local system.

When the Web Service does not reply through a synchronous response, the remote system can call a Web Service on the local system (calling system) to send the response. The local system will be in waiting mode to receive a call from the remote system. A waiting mode can be implemented in a workflow system; for example, the one being used for ARCHIBUS Service Desk and ARCHIBUS On Demand Work. In other applications, asynchronous communications can be implemented using a simple status field that changes value when the response is received.

Web Services have many advantages, such as being platform or language-independent, and security can be provided if needed. Moreover, binary data can be sent using Web Service attachments. Since all data is sent using standard http and XML over the Web, problems with firewalls are minimized.

10.5 SAP Interface Components

SAP is built around objects that contain business logic. Object data can have access rights and data can be blocked when it becomes invalid. SAP provides different interface models for accessing data, depending on application.

Protocols to be used in SAP:

• BAPI: The Business Application Programming Interfaces allow object-oriented access to the SAP system through methods for the business object types. Together with the business object types, BAPIs define and document the interface standard at the business level. If a method is called in the same module, BAPI is the protocol to be used.

• RFC: A Remote Function Call (RFC) is the call of a function module that runs in a different system to the calling program. Although it is also possible to call a function module in the same system as the RFC, normally RFCs are used when the caller and the called function module run in the same system.

• Web Service: In the SAP Web Application Server, SOAP Runtime provides a mechanism for using the SOAP protocol for accessing and calling RFC-capable function modules via HTTP. When integrating with



13

another system, the interface between the systems is defined by a Web Service. Integration between ARCHIBUS and SAP is, thereby, established by defining Web Services.

SAP supports a number of asynchronous transaction protocols such as Batch Data Communication (BDC), Batch Input (BI) and Direct Input (DI) when using flat files. The ARCHIBUS Windows Client/Server also provides means of importing and exporting files in XML or Excel format.

10.6 ARCHIBUS Web Services

Since Version 18 or higher of Web Central, the focus on integration in ARCHIBUS is Web Service-oriented. In previous versions, there was no standard Web Service support. Standard Java WS support is incorporated by using the CXF library. ARCHIBUS Web Central provides the capability to expose Web Service access to the Web Central event handler interface.

Implementing Web Services

Web Services in ARCHIBUS can be implemented using JAX-RPC and Apache AXIS2, but in recent releases of ARCHIBUS the standard Java WS using the CXF libraries is preferred.

Implementation of a Web Services consists of defining an interface and implementation class for the Web Service methods. Classes get annotated to define the Web Service definition.

@WebService(name = “BookingService”)public interface BookingService { …}@WebService(endpointInterface = “com.archibus.eventhandler.webservice.BookingService”, serviceName = “BookingService”)public class BookingServiceImpl implements BookingService { …}

The implementation class is defined as a Spring bean. The endpoint is defined using the jaxws tag referencing the Spring bean implementation and exposed address of the service.

<bean id=”bookingService-remote” class=”com.archibus.eventhandler.webservice.BookingServiceImpl” />

<jaxws:endpoint id=”bookingService-ws” implementor=”#bookingService-remote” address=”/BookingService”/>

In the web.xml the cxf filter mapping is defined, which will define the external url mapping for the Web Service.

<servlet> <servlet-name>CXFServlet</servlet-name> <servlet-class> org.apache.cxf.transport.servlet.CXFServlet </servlet-class> <load-on-startup>3</load-on-startup> </servlet>

 <servlet-mapping> <servlet-name>CXFServlet</servlet-name> <url-pattern>/cxf/*</url-pattern> </servlet-mapping>

 <filter-mapping> <filter-name>springSecurityFilterChainRemoting</filter-name> <url-pattern>/cxf/*</url-pattern> </filter-mapping>

Calling a Web Service in ARCHIBUS

Calling a Web Service in ARCHIBUS is straightforward. Using the WSDL, the required Java code can be generated. The method may require input parameters and output parameters. The result of the code generation is a service class that will define a method for retrieving a port that implements the remote service methods.

Receiving Response from SAP

When a Web Service is implemented in ARCHIBUS, the function can be called by an external system. If you want to access Web Central Event handlers, you should be able to create a context object. Refer to ARCHIBUS documentation for specific details.

10.7 Best Practices

Database Synchronization

Never use the JDBC or ODBC directly to update data between two systems. Data exchange should always be defined by an API that provides consistency and security between the two systems. Updating the database directly can harm the database consistency and should be prevented.

Decouple Components

When components are loosely coupled, systems become more stable and scalable. This is a good practice, but make sure integrity and consistency of the data is always maintained.

Components that are decoupled can be built as asynchronous services. This prevents system overloading



15

and improves scalability. When dealing with high volumes of data in batch processing, this becomes an important issue. Optimization and possible partitioning (chunking) must be examined.

Security Best Practices

Web Services can be secured using authentication and using secure connections. The firewall must be configured to define connection security between the two systems. For SSL connections you will need a certification from an external authority like VeriSign or Entrust. Data exchange can be secured by using encryption. Encryption and decryption may increase the processing load.

Security requirements depend on the system architecture. When both systems are only accessible inside the organization, security measures are simpler than communications for systems in different locations.

ARCHIBUS Web Central uses Spring Security for authentication in Web Central. Web Service communication can be performed by creating a “system user” or using a custom authentication implementation.

11. REFERENCES

1. ARCHIBUS Inc. ARCHIBUS Web Central User Guide and System Management Help. [Online Help] 2. SAP Modules Introduction. SAP Jobs, Online SAP Training, SAP Access, SAP Tutorials, SAP Articles, SAP Resume, What is SAP and more. [Online] http://www.thespot4sap.com/.

About ARCHIBUS, Inc.ARCHIBUS is the #1 global provider of real estate, infrastructure, and facilities management solutions and services with the total annual expenditures for ARCHIBUS-related products and services exceeding $1.7 Billion (USD). Through effective innovation and business transformation, ARCHIBUS users save their organizations over $100 billion annually. With ARCHIBUS, organizations can use a single, comprehensive, integrated solution to make informed strategic decisions that optimize return-on-investment, lower asset lifecycle costs, and increase enterprise-wide productivity and profitability. ARCHIBUS is the world-wide proponent for the creation of ubiquitous environmental sustainability.

More than 4,000,000 ARCHIBUS enterprise and Web users collectively manage over 5,000,000 properties, with organizations reporting facilities-related cost savings as high as 34%. With over 1,600 ARCHIBUS Business Partners, local and regional support worldwide is available in over 130 countries and in over two dozen languages. Headquartered in Boston, Massachusetts, ARCHIBUS, Inc. has pioneered computer-aided infrastructure and facilities management technologies since 1982. For more information, visit archibus.com.

ARCHIBUS, Inc. acknowledges its Business Partner, PROCOS Group, for the substantial contribution in providing information for this White Paper. PROCOS Group is an international network of consultants in Facility Management and Facilities Planning based in Belgium, with offices throughout Europe.

ARCHIBUS White Paper: ARCHIBUS – SAP...

Documents

Transcript of ARCHIBUS White Paper: ARCHIBUS – SAP...