integration solution development guide - news - … basic understanding of key fields in projects;...

Integration Solution Development Guide

Applicable Releases

SAP Enterprise Project Connection 2.0

Document Classification: Customer

Document Version

1.1 - October, 2012

SAP ENTERPRISE PROJECT

CONNECTION (EPC)

SAP Enterprise Project Connection Integration Solution Development Guide

© Copyright SAP AG 2012 of 55

Copyright

© Copyright 2012 SAP AG. All rights reserved

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The

information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, iSeries,

pSeries, xSeries, zSeries, eServer, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, S/390 Parallel Enterprise Server, PowerVM, Power

Architecture, POWER6+, POWER6, POWER5+, POWER5, POWER, OpenPower, PowerPC, BatchPipes, BladeCenter, System Storage, GPFS,

HACMP, RETAIN, DB2 Connect, RACF, Redbooks, OS/2, Parallel Sysplex, MVS/ESA, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and

Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the

United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix

Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of

Technology.

Java is a registered trademark of Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, Clear Enterprise, SAP BusinessObjects Explorer, and other SAP products and services

mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other

Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP

France in the United States and in other countries.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves

informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for

informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with

respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty

statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Disclaimer

Some components of this product are based on Java™. Any code change in these components may cause unpredictable and severe

malfunctions and is therefore expressively prohibited, as is any decompilation of these components.

Any Java™ Source Code delivered with this product is only to be used by SAP’s Support Services and may not be modified or altered in any way.



1 Introduction .......................................................................................................................................... 5

1.1 Intended Audience ........................................................................................................................ 5

1.2 Prerequisite Documentation ......................................................................................................... 6

1.3 Architecture Overview .................................................................................................................. 6

2 Information Architecture ...................................................................................................................... 9

2.1 Canonical Information Model ....................................................................................................... 9

2.2 Local Information Model............................................................................................................... 9

2.3 Adaptive Information Model ........................................................................................................ 9

3 Operations (Workflow) ....................................................................................................................... 10

3.1 Understanding Operation ........................................................................................................... 10

3.2 Steps ............................................................................................................................................ 12

3.3 Calling Operations as a RESTful Service ...................................................................................... 13

3.3.1 Synchronous (Blocking) Call ................................................................................................ 14

3.3.2 Asynchronous (Non-blocking) Call ...................................................................................... 14

3.4 Listing Operations ....................................................................................................................... 15

4 Adaptors .............................................................................................................................................. 16

4.1 PrimaveraAdaptor ....................................................................................................................... 16

4.1.1 Adaptor Methods ................................................................................................................ 16

4.2 JRAAdaptor (SAPAdaptor) ........................................................................................................... 23

4.3 Microsoft Project Server Adaptor ............................................................................................... 25

4.3.1 Architecture and Concept ................................................................................................... 25

4.4 File Adaptor ................................................................................................................................. 26

4.5 Looping Adaptor ......................................................................................................................... 26

4.5.1 Usage Examples .................................................................................................................. 27

5 Understanding the Transformation Pipeline ...................................................................................... 31

5.1 Process Overview ........................................................................................................................ 31

5.2 Process Example ......................................................................................................................... 32

6 Development environment setup ....................................................................................................... 38

6.1 Development Mode .................................................................................................................... 38



6.2 Tools and Development Environment ........................................................................................ 38

6.3 Managing Customization Changes .............................................................................................. 38

7 Implementing Custom Mappings ........................................................................................................ 38

7.1 Mapping an SAP Project to an Enterprise Project Structure in Oracle Primavera ...................... 39

7.2 Mapping an SAP Work Order to an Oracle Primavera Project ................................................... 44

7.3 Mapping an SAP Work Order to an Enterprise Project Structure in Oracle Primavera .............. 47

8 Customizing Java Adaptor Rules ......................................................................................................... 49

8.1 Project setup in NWDS ................................................................................................................ 50

8.2 CRUD Rules Implementation....................................................................................................... 53

8.3 Importing New Rules ................................................................................................................... 55



1 Introduction SAP Enterprise Project Connection provides an integration platform that is bundled with a template

sample solution to accelerate customer specific implementation. The template solution provides an

integration scenario between SAP Project Systems, SAP Plant Maintenance, and third party enterprise

project management system i.e. Oracle Primavera. It also provides fine and coarse grained services to

develop integration solution between PLM and Microsoft Project Server. Customers will often find it

desirable to enhance this template sample solution to provide the specific data mappings, business rules

processing, and direction of data flow to meet the requirements of their own business processes.

1.1 Intended Audience This guide is intended for technical professionals that are familiar with XML and XML processing

technologies such as XSL. A familiarity with the Java programming language is also helpful for

accomplishing more complex customizations and implementation of data processing logic within the

integration solution.

As the product is designed to integrate with third party products, such as Oracle Primavera and

Microsoft Project, an understanding of the third party applications is also needed to correctly interface

the data with them in a correct and meaningful manner.

Following is the list of functional and technical skills required for SAP EPC integration solution

development and maintenance.

1. Functional skills:

Knowledge of SAP Project Systems (PS) in ECC 6.0+

o Familiarity with transactions in ERP for PS functions and data.

o Viewing Projects.

o Editing Projects.

o Creating Actual Costs for Projects.

o Basic understanding of key fields in Projects; WBS, Networks, dates, costs, resources,

location data.

o How to locate key fields in Projects; WBS, Networks, dates, costs, resources, location

data.

Knowledge of SAP Plant Maintenance (PM) in ECC 6.0+.

o Familiarity with transactions in ERP for PM functions and data.

o Viewing Work Orders and Operations.

o Editing Work Orders and Operations.

o Creating different kinds of Cost Activities.

o Basic understanding of key fields in Work Orders; Networks, Operations, dates, costs,

resources, location data.

o How to locate key fields in Work Orders; Networks, Operations, dates, costs, resources,

location data.

Knowledge of Oracle’s Primavera or Knowledge of Microsoft Project.



o Basic Understanding of Project Scheduling tool and data.

2. Technical skills:

Familiarity with XML documents.

Experience working with XSLT 2.0.

Expert in BAPI (function module) execution (read/write) and debugging.

Good java knowledge, ability to read and understand code from an object oriented stand

point.

Good ABAP knowledge, ability to write custom function module, create custom transaction

etc.

Familiarity with SAP NetWeaver Development Studio.

Familiarity with NetWeaver 7.2.x and 7.3.x AS Java stack (deployment and debugging).

1.2 Prerequisite Documentation In order to use this guide, it is necessary to have a familiarity with the overall architecture and familiarity

of the SAP Enterprise Project Connection product and solution. Before attempting to implement

customizations to the product, one should become familiar with the following documentation:

SAP Enterprise Project Connection Installation Guide

SAP Enterprise Project Connection User Guide

SAP Enterprise Project Connection Operations Guide

SAP Enterprise Project Connection Security Guide

1.3 Architecture Overview SAP Enterprise Project Connection is designed based on an SOA (service-oriented architecture) and is

deployed across both the ABAP and Java stack. SOA is used to provide a loosely coupled and highly

configurable platform for designing data orchestration.

The Java stack portion of the deployment provides data services and integration services. Data service

provides the ability to access data from an interface for data integration, reporting or data analytics

purpose. Integration services compose data services with transformation and business rules to combine

or move data between systems. The java stack is also where the ability to make connections to SAP ERP

and third party enterprise project management systems resides. The user interface and function

modules are packaged into an Add-on (/SEPC/package) that is deployed into the ABAP stack. The user

interface is surfaced through SAP GUI classic.

The following figure shows the main building blocks of SAP Enterprise Project Connection product:

ABAP Add-on and Integration Engine (Integration Service Component).



Oracle Primavera

R

http

ap

i

SAP NetWeaver

CE Cluster

W

e

b

D

i

s

p

a

t

c

h

e

r

ABAP

Add-on

SAP

Gui

NetWeaver CE DB

Integration Service

Component

NetWeaver Dialog Instance(s)

R

SAP ERP

ECC 6.0

JC

o

R

Microsoft Project

Server 2007/2010

R

WS

In following figure, the product architecture is depicted, including some internal product communication

architecture and technologies. This shows a level of detail below to provide a view of the organization

for functional responsibility within the technology.

Data Service

SAP GUI

SAP EPC

Addon

NetWeaver

APIBrowser

SAP EPC SC

SAP EPC CTC SC

SAP EPC

Database

(NetWeaver)

Adaptors

SAP JRAMicrosoft Project

ServerPrimavera

Integration Service Component

Business SystemsSAP ERP

ECC 6.0

Microsoft Project

Server 2007/2010

Oracle

Primavera

SAP EPC Configuration UI

CTC Config

Content

Environment

Service

Destination

Service

Engine

Service

Transfer

Orders

Transaction

Transfer

Result

Transaction

Transfer

Projects

Transaction

R

R

NW

Configuration

Scenario UI

Integration

Solution

Transfer

Result

SAP JRA

VSI API

Logging

API

UME API

R

R

Operation

Runner

RunQue

Configuration

Manager

Data

Orchestration

Service

Data Service

OIM

Web Service

Restful Service

CIM

LIM

AIMLog Manager

Persistency EJB Layer

Rules

Execution

Metadata

Service

R

Solution

Configuration

Jco/RFC Web service Integration API

Http

Dependency

Injection (IOC)

The following diagram provides a graphical view of SAP Enterprise Project Connection deployment in the

SAP landscape excluding third party project management systems. EPC consumes its integration solution

data which is basically a set of XML documents and meta-data descriptions that can be deployed onto



the file system for development purpose or can be deployed to database for production purpose. This

integration solution is independent of the actual EPC java server component and ABAP Add-on

component. These solution artifacts provide the data mappings, business rules and meta-data that tell

EPC engine what to do when n integration data service is invoked. This means that each customer can

have unique solution tailored to their needs without changing the EPC product.

EPC

Integration

Services

Component

SAP JRA

Component

Add On

Component

Transfer Requests/Results

Data Access

RFC

EPC

Integration

Solution

SAP NetWeaver AS JavaSAP NetWeaver ABAP

SAP ERP ECC 6.0

Following figure shows data flow and communication between different SAP EPC components and end point systems.

SAP EPC

Integration Service

Component

SAP JRA

SAP EPC

P6Adaptor

SAP EPC

Microsoft Project

Server Adaptor

SAP EPC Add-on

Component

SAP ERP

Oracle Primavera

Microsoft Project

Server 2007/2010

R

R

R

R

Http

Jco/RFC

Integration API

WS



2 Information Architecture The SAP Enterprise Project Connection product is built around a specific information architecture that

must be understood in order to successfully implement integration scenarios in the product. The

artifacts of the information architecture map to XML and XML processing documents that are stored in

the configuration layer of the product.

The diagram below provides a visual reference for the information model components described in the

following subsections.

SAP Enterprise Project Connection Information Architecture

2.1 Canonical Information Model The Canonical Information Model (CIM) is the document that contains the non-vendor specific

representation of the data entities (Projects, Work Orders, etc) for translation and high-level business

rules processing. Normally, it is not necessary to modify the structure of the CIM, although the flexibility

of the system does allow for that if required.

2.2 Local Information Model The Local Information Model (LIM) is the document that contains the vendor/module specific

representation of the data entities (Projects, Work Orders, etc). These contain an XML version of the

data in a structure and format that is compatible with, and similar to the back-end system from which

the data came, or to where the data is being sent.

2.3 Adaptive Information Model The Adaptive Information Model (AIM) is a set of XML processing documents, usually in the form of XSL,

that provide the logic for translation between the LIM and CIM. Essentially, this is where data mappings,

directionality of data flow, functional rules, and constraints on valid data can be implemented. These



documents are where the majority of the work for implementation of custom integration scenarios will

be performed.

Utilization of XML for definition and deployment of these information models ensures portability, ease

of editing and use and extensibility information architecture for future applications maintenance and

development.

3 Operations (Workflow) The primary controlling XML document for the overall information architecture is the Operation.XML

document. This document provides the declarations and definitions for all the integration scenarios

published into the integration server. It uses XML and a declarative approach to defining the actual

integration flows that will be processed by the integration engine at run-time. The purpose of an

Operation is to define the relations between the different parts of the information model: CIMs, AIMs,

and LIMs and then publish the resulting integration as a service. Operations are generally called via a

service interface using a standardized HTTP URI. (Schema: Operations.xsd)

3.1 Understanding Operation An Operation contains all the instructions necessary to accomplish an end-to-end integration flow. In a

development mode environment, the Operations documents are located in the

“config/datapath/operations” folder under the installation root. There are usually one or more

operations definitions deployed with the system, with the naming convention for the operations files

being <workflow name>-operations.xml. This provides some modularization of the high level

deployment of integration scenarios to the system.

When considering making implementation changes and customizations to an implementation, the

Operations document is where one should begin. Not only does this document contain the complete set

of integration scenarios available, it also provides the implementation instructions and references to the

supporting implementation files (XSL, XQUERY, etc) that are used to actually perform the work on the

information models.

An Operation is defined via specifying any number of Steps that act on LIMs, CIMs, and/or AIMs. Each

Step takes input in the form of parameters or XML documents, and outputs an XML document.

The XSD for an Operation is published with the SAP Enterprise Project Connection product. It is

recommended to familiarize oneself with the XSD, and to use this for document validation whenever

modifying the Operations document before publishing.

Skeleton of Operation XML:

4 <Operations xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="Operations.xsd" namespace="" version="">

5 <Operation cache="false" name="">

6 <Steps>

7 

<Step name="" type="">

<IM type="LIM"/>

<Adaptor id=""/>

<Method name=""/>

<Params>

<Param name=""/>

</Params>

<Dependencies>

<Dependency stepName=""/>

</Dependencies>

</Step>



<Step name="" type="APPLY">



<IM type="">${llx.home}/</IM>

<Params>

<Param name=""/>

</Params>

<Dependencies>


</Dependencies>

</Step>

</Steps>

<ParamSets/>

</Operation>

</Operations>

The following code snippet shows a simple example of an Operation.

<Operation name="GetServerVersion" cache="true">

<Steps>

<Step name="getServerVersion" type="GET">

<IM type="LIM"/>

<Adaptor id="SystemAdaptor"/>

<Method name="serverVersion"/>

<Params>

<Param name="raw"/>

</Params>

<Dependencies/>

</Step>

<Step name="ConvertLimToCim" type="APPLY">

<IM type="AIMXQuery">${llx.home}/config/datapath/im/System/WrapAsCIM.xquery</IM>

<Params>

<Param name="limParam">{getServerVersion}</Param>

</Params>

<Dependencies/>

</Step>

</Steps>

<ParamSets/>

</Operation>



The “name” attribute of the Operation is the service name that will be published by the integration

server. More information about calling these services will follow later in this guide. The Operation

contains, and is in fact defined by, the set of Steps specified within the Operation.

In the code snippet above, a Step named “getServerVersion” is shown with the type “GET”. This specifies

that the Step will retrieve the information, in this particular case from server itself. The step expects one

parameter named “raw”. This parameter will be passed by the caller of the service:

user=testuser&raw=false

“ConvertLimToCIM” is shown with a type “APPLY”. This specifies that the Step will modify a XML

document currently within the scope of the Operation. The Step has an IM (Information Model) type of

“AIMXsl”, telling the server that it will process an Adaptive Information Model using XSL. The name and

location of the XSL document to utilize is the payload. Further, the Step is configured to accept the

parameter named “limParam”. The Param name is arbitrary and also specific to the sample Operation.

Operation must have at least 2 steps, and at least one step of type “APPLY”

7.1 Steps There are essentially three types of Steps that one should be concerned with. They are “GET”, “SET”,

and “APPLY”.

GET Step interacts with an adaptor to retrieve data from a back-end system.

SET Step interacts with XML documents and an adaptor to send data to a backend system.

APPLY Step interacts with XML documents and provides processing instructions, usually in the

form of an XSL document, for the manipulation of the contents of the various XML documents

being processed within the system.

The integration server can pass the output XML of one step as input to another Step simply by

referencing the Step name. In the code snippet above, note that the input value for the Step named

“ConvertLimToCIM” is the name from the previous step, “getServerVersion”, which has been

surrounded by braces. This allows the “ConvertLimToCIM” Step to operate on the XML document

output from the “getServerVersion” step. This also tells the server that there is an information

dependency between the steps, allowing the engine to optimize the processing of the Operation.

It is not necessary to interact with the Dependencies element in normal circumstances as the integration

engine determines these at runtime based on the references between Steps in the input parameters.

<Step name="" type="">

<IM type="LIM"/>

<Adaptor id=""/>

<Method name=""/>

<Params>

<Param name=""/>

</Params>

<Dependencies>


</Dependencies>

</Step>



<Step name="" type="APPLY">



<IM type="">${llx.home}/</IM>

<Params>

<Param name=""/>

</Params>

<Dependencies>


</Dependencies>

</Step>

7.2 Calling Operations as a RESTful Service Operations are exposed automatically by the integration server as RESTful services that can be called via

standardized URIs over HTTP. REST (Representational State Transfer) is a style of software architecture

that can, among other things, allow domain-specific data to be transferred over HTTP (Hypertext

Transfer Protocol) from the client to the server. The form the URI is as follows:

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/<Operation_Name>/<Response_Type>

Where:

<server_name> is the name of the Netweaver Server where the EPC installation is running

<port> is the port number on which the installation has been configured in the NetWeaver

installation (default is 50000)

<Operation_Name> is the name of the Operation from the Operation XML document

<Response_Type> is one of CIM, or Job, depending on whether the response document is

desired synchronously, or just the Job of the request such that the results can be fetched at a

later time.

The URL must be called with an HTTP Put command, and the following parameters must be provided in

the content as “text/xml” mime-type content: username, someInputParam, server, client, and system

number.

An example of valid parameter content is:



user=testuser&someInputParam=<Orders><Order><Id>111111</Id></Order></Orders>&

server=reserved&client=001&systemNumber=reserved

Note that the specifics for the some InputParam will be dependent on the Operation being called and

the input expected by it.

7.2.1 Synchronous (Blocking) Call

When the <Response_Type> has a value of CIM the call will return the result of the called operation,

XML document representing the result CIM. For example, GetServerVersion service call

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/GetServerVersion/CIM

Returns the XML document representing the information about current server version:

<?xml version="1.0" encoding="ISO-8859-1"?>

<CIM type="cim">

<Manifest type="War">

<Attributes name="Main">

<Property key="Implementation-Vendor" value="sap.com"/>

<Property key="Implementation-Title" value="xapps/epc/datapath-web"/>

<Property key="Implementation-Version" value="MAIN_EPC20VAL_D 20121002103431"/>

<Property key="DC-Type" value="J2EE"/>

<Property key="DC-SubType" value="WebModule"/>

<Property key="DC-Name" value="xapps/epc/datapath-web"/>

<Property key="SC-Vendor" value="sap.com"/>

<Property key="Manifest-Version" value="1.0"/>

<Property key="DC-Vendor" value="sap.com"/>

<Property key="SC-Name" value="ENTERPRISE_PROJECT_CONNECTION"/>

</Attributes>

<Attributes name="build-information">

<Property key="Build-Time" value="10:34:31 GMT-07:00 (PDT)"/>

<Property key="Created-By" value="DC BuildTool"/>

<Property key="Source-Location"

value="https://dtr6000.wdf.sap.corp:50001/dtr/ws/EPC20VAL/sap.com_ENTERPRISE_PROJECT_CONNECTION/d

ev/inactive/"/>

<Property key="Build-Date" value="2012-10-02"/>

<Property key="Build-Counter" value="20121002103431"/>

<Property key="Build-Location" value="MAIN_EPC20VAL_D"/>

</Attributes>

</Manifest>

</CIM>

The caller (client) will be blocked until the call returns. The waiting time may be significant if the

operation more complicated and performing actual work involved processing certain amount of data.

7.2.2 Asynchronous (Non-blocking) Call

When the <Response_Type> has a value of JobID the call will put a request for execution of the specified

operation and return immediately. The returned CIM document contains the submitted request ID

which can be used later to retrieve the actual response from the operation.

Using the same GetServerVersion service call as an example:

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/GetServerVersion/Job

Will return:

<?xml version="1.0" encoding="ISO-8859-1"?>

<JobIds type="cim">

<JobId>1234</JobId>



</JobIds>

Calling service GetJobResult:

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/GetJobResult/CIM

with returned JobId value as a parameter:

user=testuser&id=1234

This call returns the same XML document representing the information about current server version as

in case of using the blocking call.

Asynchronous calls are extremely useful when operating with the substantial amount of data and

processing may take some time.

7.3 Listing Operations To obtain a list of all the Operations currently published into the Enterprise Project Connection server,

the following URL may be called with HTTP Put command:

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/GetOperations/CIM

Since GetOperations service does not require any parameters, the parameter content is:

user=testuser

The returned XML document will contain all operations, thus if more than one operations file is

deployed on the server, the document will contain operations from all operations xml files.

Alternatively, HTTP Get command may be used for the same purpose:

http://<server_name>:<port>/datapath-web/rest/users/epc_user/services/GetOperations

Another useful service exposed by Enterprise Project Connection server is GetOperation. The result of

this call will contain XML for the particular operation specified as a parameter for the call:

http://<server_name>:<port>/datapath-web/restful/1.0/Operation/GetOperation/CIM

Parameter content is:

user=testuser&operation=operation_name

where operation_name is the name of the desired operation.

Alternatively, HTTP Get command may be used for the same purpose:

http://<server_name>:<port>/datapath-web/rest/users/epc_user/services/GetOperation/operation_name



8 Adaptors Adaptor is the part of Enterprise Project Connection product that provides connectivity to external end-

point systems such as SAP PM and PS, Oracle Primavera, Microsoft Project Server, etc., translates

information requests and content from the individual protocols and interfaces required by each system

into XML and enables data retrieval and modification on those external systems. The adaptor’s methods

are exposed by EPC and accessible through standard service interfaces such as Web Services (SOAP) and

REST.

Some adaptors are the internal part of Enterprise Project Connection and enable some extended

functionality like writing on the server’s file system, extending workflow capabilities (Looping adaptor),

etc.

8.1 PrimaveraAdaptor PrimavearAdaptor uses Oracle Primavera Integration API to process project information. This adaptor

also provides ability to refine CRUD call using java based rules. This adaptor configuration is configured

using configuration scenario.

8.1.1 Adaptor Methods

8.1.1.1 ping

This is used for testing Primavera connection. This method checks the connection to the Oracle

Primavera system using configured parameters and returns Oracle Primavera connection status and

connection information.

Method: ping

Workflow Step:

<Step name="Ping" type="SET">

<IM type="LIM"/>

<Adaptor id="PrimaveraAdaptor"/>

<Method name="ping"/>

<Params/>

<Dependencies/>

</Step>

Parameters: None

Since: 1.0

Returns: XML with connection info if connection to the system is successful or error detail in case of

connection failure or exception details with stack trace.



8.1.1.2 read

Retrieves requested data from Oracle Primavera system in LIM(Local Information Model) XML format.

(Schema: p6project.xsd.)

Method: read

Workflow Step:

<Step name="ReadPrimaveraProjects" type="SET">

<IM type="LIM"/>


<Method name="read"/>

<Params>

<Param name="crudParamsXml"/>

</Params>

<Dependencies/>

</Step>

Parameters:

1. CrudParamsXml

CRUD parameter xml document contains any additional parameter name, value pair needed to

filtering the data or to apply data/business. Make sure that this document passes

“crudParameters.xsd” schema validation.

NOTE: If crud parameter xml document is empty, null or contains invalid rule name then this

operation returns list of all Primavera projects master data.

<CrudParameters type="LIM" version="1.0">

<CrudParameter GUID="projectWhereClause">

<Name>projectWhereClause</Name>

<Value>Id in (‘YOUR_VALUE’)</Value>

</CrudParameter>

<CrudParameter GUID="Read.doNotProcess">

<Name>Read.doNotProcess</Name>

<Value></Value>

</CrudParameter>

</CrudParameters>

Supported whereclause parameter: o Name

projectWhereClause activityWhereClause

o Value Value of this param is a valid SQLwhere clause allowed by Oracle Integration

API.

“Read.doNotProcess” parameter: This parameter is used for filtering out unwanted objects data to reduce the size of output xml and also helps in increasing performance of the integration. Value contains coma separated list of objects as listed below.



o Name Read.doNotProcess

o Value Coma separated values of objects.

Following are the supported objects:

UDFValue,Calendar,ActivityCodeType,ActivityCode,ActivityCodeAssignment

,ResourceCodeType,ResourceCode,ResourceCodeAssignment,ProjectCodeT

ype,ProjectCode,ProjectCodeAssignment,Project,Calendar,WBS,ProjectRes

ource,ProjectResourceQuantity,ProjectBudgetChangeLog,ProjectRisk,WBS

Milestone,ProjectNote,ProjectThreshold,ProjectSpendingPlan,ProjectFundi

ng,ProjectEstimate,ActivityCodeType,Activity,ResourceAssignment,Activity

Expense,ActivityNote,ActivityStep,Relationship,ActivityPeriodActual,Project

Issue,ResourceAssignmentPeriodActual,Document,ProjectDocument,EPS,R

esourceRole,Resource,Role,ProjectResourceCategory,UnitOfMeasure,CostA

ccount,Currency,UDFType,UDFCode,ExpenseCategory,NotebookTopic,RiskT

ype,WBSCategory,FundingSource,ThresholdParameter,OBS,Shift,ResourceC

urve,ResourceRate,FinancialPeriod,DocumentCategory,DocumentStatusCo

de

Since: 1.0

Returns: LIM (Local information model) XML. (Schema: p6project.xsd)

See Also: readProject method which provides faster retrieval of data but supports only one project id in

the whereclause.

NOTE: Use following step after the “ReadPrimaveraProjects“ step above to convert LIM (Local

information model) to standard Project CIM(Canonical Information Model) format.

<Step name="BuildProjectCIM" type="APPLY">

<IM type="AIMXsl">${llx.home}/config/im/primavera/PrimaveraLIMToProjectCIM.xsl</IM>

<Params>

<Param name="inputDoc">{ReadPrimaveraProjects}</Param>

</Params>

<Dependencies/>

</Step>

8.1.1.3 readProject

Retrieves project data from Oracle Primavera system in LIM(Local Information Model) XML format.

(Schema: p6project.xsd)

Method: read

Workflow Step:



<Step name="ReadPrimaveraProject" type="SET">

<IM type="LIM"/>


<Method name="readProject"/>

<Params>


</Params>

<Dependencies/>

</Step>

Parameters:

1. CrudParamsXml

CRUD parameter xml document contains any additional parameter name, value pair needed to

filtering the data or to apply data/business. Make sure that this document passes



<CrudParameter GUID="projectWhereClause">

<Name>projectWhereClause</Name>

<Value>Id in (‘YOUR_VALUE_ONLY_ONE_ID’)</Value>

</CrudParameter>

<CrudParameter GUID="Read.doNotProcess">

<Name>Read.doNotProcess</Name>

<Value></Value>

</CrudParameter>

</CrudParameters>

Supported whereclause parameter: o Name

projectWhereClause activityWhereClause

o Value Value of this param is a valid SQLwhere clause allowed by Oracle Integration

API.

“Read.doNotProcess” parameter: This parameter is used for filtering out unwanted objects data to reduce the size of output xml and also helps in increasing performance of the integration. Value contains coma separated list of objects as listed below.

o Name Read.doNotProcess

o Value Coma separated values of objects. Following are the supported objects:

UDFValue,Calendar,ActivityCodeType,ActivityCode,ActivityCodeAssignment

,ResourceCodeType,ResourceCode,ResourceCodeAssignment,ProjectCodeT

ype,ProjectCode,ProjectCodeAssignment,Project,Calendar,WBS,ProjectRes

ource,ProjectResourceQuantity,ProjectBudgetChangeLog,ProjectRisk,WBS



Milestone,ProjectNote,ProjectThreshold,ProjectSpendingPlan,ProjectFundi

ng,ProjectEstimate,ActivityCodeType,Activity,ResourceAssignment,Activity

Expense,ActivityNote,ActivityStep,Relationship,ActivityPeriodActual,Project

Issue,ResourceAssignmentPeriodActual,Document,ProjectDocument,EPS,R

esourceRole,Resource,Role,ProjectResourceCategory,UnitOfMeasure,CostA

ccount,Currency,UDFType,UDFCode,ExpenseCategory,NotebookTopic,RiskT

ype,WBSCategory,FundingSource,ThresholdParameter,OBS,Shift,ResourceC

urve,ResourceRate,FinancialPeriod,DocumentCategory,DocumentStatusCo

de

Since: 1.0

Returns: LIM (Local information model) XML. (Schema: p6project.xsd)

NOTE: readProject method which provides faster retrieval of data but supports only one project id in the

whereclause.

NOTE: Use following step after the “ReadPrimaveraProjects“ step above to convert LIM (Local

information model) to standard Project CIM(Canonical Information Model) format.


<IM type="AIMXsl">${llx.home}/config/im/primavera/PrimaveraLIMToProjectCIM.xsl</IM>

<Params>

<Param name="inputDoc">{ReadPrimaveraProjects}</Param>

</Params>

<Dependencies/>

</Step>

8.1.1.4 createOrUpdate

Writes data to Oracle Primavera system and returns the resulting Audit Response xml. This operation

creates missing data and updates existing Primavera data. Create or update action at object or field level

is controllable using events used in java rule file or from the instructions passed in the CRUDParamsXml

file. Response from this operation is an Audit Response xml (Schema: auditResponses.xsd).

Method: createOrUpdate

Workflow Step:

<Step name="WritePrimaveraProjects" type="SET"> <IM type="LIM"/>


<Method name="createOrUpdate"/>

<Params>

<Param name="dataXml"></Param>


</Params>

<Dependencies/>

</Step>



Parameters:

1. dataXml – LIM XML document. Make sure that this document passes “p6project.xsd” schema

validation.

NOTE: if you have standard Project CIM document then use following step to convert Project CIM

to Primavera LIM XML document.

<Step name="TransformPrimaveraLIM" type="APPLY"> <IM type="AIMXsl">${llx.home}/config/im/primavera/ProjectCIMToPrimaveraLIM.xsl</IM>

<Params>

<Param name="inputDoc"/>

</Params>

<Dependencies/>

</Step>

2. CrudParamsXml – (Optional). Use this document to restrict writing of the data at object or at field

level using rules. Pass rule name in crud parameter xml. Make sure that this document passes



<CrudParameter GUID="Create.doNotProcess">

<Name>Create.doNotProcess</Name>

<Value>LIST_OF_OBJECTS</Value>

</CrudParameter>

<CrudParameter GUID="Update.doNotProcess">

<Name>Update.doNotProcess</Name>


</CrudParameter>

<CrudParameter GUID="WriteRuleSetFilter">

<Name> WriteRuleSetFilter </Name>

<Value>YOUR_RULE_NAME</Value>

</CrudParameter>

</CrudParameters>

o Supported parameters for CrudParamsXml: (Optional)

1. Name

Create.doNotProcess

Value

Coma separated values of objects. Following are the supported objects:

EPS,Code,Assignment,ActivityNote,ActivityCodeType,ActivityCode,Activity,Expe



nse,NotebookTopic,Project,ProjectCode,ProjectCodeType,

ProjectNote,Relationship,Resource,ResourceCode,ResourceCodeType,UDF,UDF

Type,WBS,WBSNote,WBS

2. Name

Update.doNotProcess

Value

Coma separated values of objects. Following are the supported objects:





3. Name

WriteRuleSetFilter

Value

For java rules, use last part of your java rules package name as rule name.

Since: 1.0

Returns: Response from this method is an Audit Response XML (Schema: auditResponses.xsd).

8.1.1.5 delete

Deletes data from Primavera and returns delete action response xml. This operation deletes data at

Primavera object level only. i.e. EPS, Project, WBS, Activity, Relationship etc. Response from this

operation is in Audit Response format (auditResponses.xsd).

Method: delete

Workflow Step:

<Step name="DeletePrimaveraProjects" type="SET"> <IM type="LIM"/>


<Method name="delete"/>

<Params>

<Param name="limStr"></Param>


</Params>

<Dependencies/>

</Step>

Parameters:

1. limStr – LIM XML document. Make sure that this document passes “p6project.xsd” schema

validation.



NOTE: if you have standard Project CIM document then use following step to convert Project CIM

to Primavera LIM XML document.

<Step name="TransformPrimaveraLIM" type="APPLY">

<IM

type="AIMXsl">${llx.home}/config/im/primavera/ProjectCIMToPrimaveraLIM.xsl</IM>

<Params>

<Param name="inputDoc"/>

</Params>

<Dependencies/>

</Step>

2. CrudParamsXml – (Required). Use this document to instruct adaptor explicitly for data deletion.

Make sure that this document passes “crudParameters.xsd” schema validation.


<CrudParameter GUID="Delete.process">

<Name>Delete.process</Name>


</CrudParameter>

</CrudParameters>

o Supported parameters for CrudParamsXml: (Optional)

1. Name

Delete.process

Value

Coma separated values of objects or “*” for deletion of all the objects.

Following are the supported objects:





Since: 1.0

Returns: Response from this method is an Audit Response XML (Schema: auditResponses.xsd).

8.2 JRAAdaptor (SAPAdaptor) JRAAdaptor uses SAP Java Resource Adapter (SAP JRA). JRA is a wrapper around SAP JCO. JRAAdaptor

provides connectivity to SAP ERP and processes the requests to execute function module (BAPI).



JRAAdaptor adaptor exposes following methods:

executeCallAdaptor (Since: 2.0)

executeCallAdaptorEx (Since: 2.0)

getRequestScehma (Since: 2.0)

getResponseSchema (Since: 2.0)

ping (Since: 2.0)

The code snippet illustrates the usage of JRAAdaptor methods in the operations.

<Step name="ExecuteBAPIRequest" type="GET">

<IM type="LIM"/>

<Adaptor id="JRAAdaptor"/>

<Method name="executeCallAdaptor"/>

<Params>

<Param name="bapiName"/>

<Param name="xmlRequest"/>

<Param name="server"/>

<Param name="client"/>

<Param name="systemNumber"/>

</Params>

<Dependencies/>

</Step>

<Step name="ExecuteMultipleBAPIRequests" type="GET">

<IM type="LIM"/>


<Method name="executeCallAdaptorEx"/>

<Params>

<Param name="bapiName"/>

<Param name="xmlRequest"/>

<Param name="server"/>

<Param name="client"/>

<Param name="systemNumber"/>

</Params>

<Dependencies/>

</Step>

<Step name="GetRequestSchema" type="GET"> <IM type="LIM"/>


<Method name="getRequestSchema"/>

<Params>

<Param name="methodName"/>

</Params>

<Dependencies/>

</Step>



<Step name="GetResponseSchema" type="GET">

<IM type="LIM"/>


<Method name="getResponseSchema"/>

<Params>

<Param name="methodName"/>

</Params>

<Dependencies/>

</Step>

<Step name="PingConnection" type="GET">

<IM type="LIM"/>


<Method name="ping"/>

<Params/>

<Dependencies/>

</Step>

8.3 Microsoft Project Server Adaptor Microsoft Project Server adaptor provides EPC with ability to read and write data into Microsoft Project

Server utilizing the Project Server Interface (PSI), a set of Web services (SOAP) built on the Microsoft

.NET Framework. The PSI exposes the functionality and data that can be used to integrate other

applications with Project Server.

8.3.1 Architecture and Concept



8.4 File Adaptor File adaptor enables EPC to read and write XML files from the server’s file system. It may be used to read

constant data, write different data such as intermediate step/operation results for troubleshooting and

analysis.

File adaptor exposes two methods:

getXmlFile

writeFile.

The code snippet illustrates the usage of those methods in the operations.

...

<Step name="ReadXml" type="GET">

<IM type="LIM"/>

<Adaptor id="FileAdaptor"/>

<Method name="getXmlFile"/>

<Params>

<Param name="filePath">${llx.home}/config/datapath/testfiles/data/someFile.xml</Param>

</Params>

<Dependencies/>

</Step>

...

<Step name="SomeProcessStep" type="GET">

...

<Step name="WriteData" type="GET">

<IM type="LIM"/>


<Method name="writeFile"/>

<Params>

<Param name="stuff">{SomeProcessStep}</Param>

<Param name="filePath">${llx.home}/logs/someData.xml</Param>

</Params>

<Dependencies/>

</Step>

8.5 Looping Adaptor Looping adaptor provides EPC with a set of key features that dramatically extend and improve data

processing capabilities that allows:

To have a “while” style loops functionality in the data flow operations

To control the batch size – amount of items to process in a single iteration within the loop

To select the type of call to use within the loop – blocking or non-blocking.

To call other operation within operation – re-use the operation’s code

Those functional extensions enable EPC to partition the data and process it in parallel in smaller

fractions that may significantly increase throughput and performance.

Additionally looping adaptor exposes several auxiliary methods that simplify the usage of the adaptor.

See the appendix for the complete list of the adaptor methods.



8.5.1 Usage Examples

All sample operations for the adaptor can be found in

/home/config/datapath/adaptor/looping_adaptor.xml

8.5.1.1 SyncSampleOperationToCall, AsyncSampleOperationToCall and

AsyncSampleOperationToCallWithResult

Those three operations are demonstrating how to call internal operation (GetServerVersion), they are

almost identical and differ only by how the call to internal operation is executed. The complete

operation:

<Operation name="SyncSampleOperationToCall" cache="false">

<Steps>

<Step name="CreateOpXml" type="SET">

<IM type="LIM"/>

<Adaptor id="LoopingAdaptor"/>

<Method name="createOpXml"/>

<Params>

<Param name="opName">GetServerVersion</Param>

</Params>

<Dependencies/>

</Step>

<Step name="AddOpParam" type="SET">

<IM type="LIM"/>


<Method name="addOpParam"/>

<Params>

<Param name="xmlOp">{CreateOpXml}</Param>

<Param name="name">raw</Param>

<Param name="value">false</Param>

</Params>

<Dependencies/>

</Step>

<Step name="OperationCall" type="GET">

<IM type="LIM"/>


<Method name="operationCall"/>

<Params>

<Param name="user"/>

<Param name="xmlOp">{AddOpParam}</Param>

<Param name="directives">0</Param>

<Param name="asyncCall">false</Param>

<Param name="waitForResult">false</Param>

</Params>

<Dependencies/>

</Step>

<Step name="CreateFinalCIM" type="APPLY">

<IM type="AIMXQuery">${llx.home}/config/datapath/im/System/MakeIntoCIM.xquery</IM>

<Params>

<Param name="limParam">{OperationCall}</Param>

</Params>

<Dependencies/>

</Step>

</Steps>

<ParamSets/>

</Operation>

The first step, CreateOpXml, utilizes auxiliary adaptor method - createOpXml - provided to help create

the operation XML parameter required for the call to internal operation. In this example we are going to

call GetServerVersion operation, so we provide the name of the operation as a value for the parameter

opName. The output of this step:



<Operation name="GetServerVersion" nameSet="">

<Params />

</Operation>

The second step, AddOpParam, utilizes another auxiliary adaptor method – addOpParam – that modifies

the operation XML and adds a parameter name and value to it, in this case the name “raw” and a value

of “false”. The addOpParam method returns the modified operation XML:

<Operation name="GetServerVersion" nameSet="">

<Params>

<Param name="raw">false</Param>

</Params>

</Operation>

addOpParam method can be called as many times as it required to add all parameters for the call.

The next step, OperationCall, is the actual call to internal operation. There are a set of the parameters

required for the operationCall adaptor method to execute the call.


“User” parameter will be passed automatically from the server to impersonate the server’s user. In

some specific cases other user can be specified to set a different identity for the call.


“xmlOp” parameter in the operation XML built by CreateOpXml and AddOpParam steps


The “directives” parameter dictates how the server is going to threat the results. There are four possible

values for this parameter that can be OR’ed:

0 – no specific instructions. The operation’s result CIM will be kept until retrieved by

GetJobResult in case of the asynchronous call or will not be kept in case of synchronous call

1 – re-run the operation if operation’s execution was terminated abnormally.

2 – persist the result of the operation permanently.

4 - discard the operation result immediately after execution is completed. This value will be

ignored if the call executed as synchronous


“asyncCall” parameter controls how the call to internal operation will be executed. Value of true will

force the call to be executed in the asynchronous manner. For the SyncSampleOperationToCall this

value is set to false, while for AsyncSampleOperationToCall and AsyncSampleOperationToCallWithResult

the value is set to true.




The “waitForResult” parameter value set to true will force the adaptor to wait for results even if the call

is set to non-blocking (asyncCall is set to true). The waitForResult parameter is ignored when asyncCall is

set to false.

The final step, CreateFinalCIM, will create the resulting CIM that will be return to the caller of the

operation.

8.5.1.2 SyncSampleLoopOperationToCall, AsyncSampleLoopOperationToCall and

AsyncSampleLoopOperationToCallWithResult

Those three operations are demonstrating how to call internal (GetServerVersion) within the loop, they

are almost identical and differ only by how the call to internal operation is executed. Steps similar to

already described in previous paragraph will be omitted.

<Operation name="AsyncSampleLoopOperationToCall" cache="false">

<Steps>

<Step name="ReadTestXml" type="GET">

<IM type="LIM"/>


<Method name="getXmlFile"/>

<Params>

<Param name="filePath">${llx.home}/config/datapath/testfiles/data/test.xml</Param>

</Params>

<Dependencies/>

</Step>

<Step name="CreateOpXml" type="SET">

...

</Step>

<Step name="AddOpParam" type="SET">

...

</Step>

<Step name="LoopOperationCall" type="GET">

<IM type="LIM"/>


<Method name="loopOperationCall"/>

<Params>



<Param name="xmlInputData">{ReadTestXml}</Param>

<Param name="condXPath">//Tests/Test</Param>

<Param name="batchSize">10</Param>

<Param name="loopInputParamName">raw</Param>


<Param name="asyncCall">true</Param>


</Params>

<Dependencies/>

</Step>


...

</Step>

</Steps>

<ParamSets/>

</Operation>

The first step, ReadTestXml will read the test XML document from the file. The XML contains:

<Tests>



<Test>

<Value>Value0</Value>

</Test>

<Test>


</Test>

...

<Test>


</Test>

</Tests>

The most important step in this operation is LoopOperationCall. Let’s examine the parameters.

<Param name="xmlInputData">{ReadTestXml}</Param>

The “xmlInputData” parameter receives the XML document containing the list of the items that call to

internal operation will iterate on.

<Param name="condXPath">//Tests/Test</Param>

The “condXPath” parameter receives XPath that will be applied to “xmlInputData” parameter value and

will produce a list of items (nodes) that call to internal operation will iterate on.


The “batchSize” parameter controls the amount of items from the list to be passed to internal operation

call for every iteration.

<Param name="loopInputParamName">raw</Param>

The “loopInputParamName” parameter specifies the name of the parameter of the internal operation

which is going to receive the list of the items to process.

8.5.1.3 Using OperationTemplate.xsl

OperationTemplate.xsl is alternative way to create operation XML for looping adaptor. The file can be

found in /home/config/im/looping/ folder.

The example of how to use OperationTemplate.xsl can be found in

/home/config/datapath/operations/sappm_p6tosap-operations.xml operation XML file. The fragment of

the operation:

<Operation name="P6toSAPController" cache="false">

<Steps>

...

<Step name="buildOpXml" type="APPLY">

<IM type="AIMXsl">${llx.home}/config/im/looping/OperationTemplate.xsl</IM>

<Params>

<Param name="inputDoc"><CIM/></Param>

<Param name="OpName">P6toSAP</Param>

<Param name="Param1Name">inputParamXml</Param>

<Param name="Param1Val"/>

</Params>

<Dependencies/>

</Step>

<Step name="LoopOperationCall" type="GET">

<IM type="LIM"/>




<Method name="loopOperationCall"/>

<Params>


<Param name="xmlOp">{buildOpXml}</Param>

<Param name="xmlInputData"/>

<Param name="condXPath">//Orders/Order</Param>


<Param name="loopInputParamName">inputParamXml</Param>




</Params>

<Dependencies/>

</Step>

...

The OperationTemplate.xsl accepts maximum of 7 parameters: operation name and 3 name/value pairs

for the parameters.

<xsl:param name="OpName"/>

<xsl:param name="Param1Name"/>

<xsl:param name="Param1Val"/>





It can be easily modified to accept additional parameters or customized for specific needs for the

particular solution implementation.

9 Understanding the Transformation Pipeline As discussed earlier, the SAP Enterprise Project Connection data integration server uses information

models and the Operation XML to specify and execute the movement and transformation of data

between business applications. In this section, how this works from a process perspective is discussed.

9.1 Process Overview The specific process that is used and the complexity of its specification are entirely determined by the

complexity of the integration and business rules required. At a high level however, most integrations

processed by the Enterprise Project Connection solutions will take one of two forms, both of which are

shown here.

The first form of the process moves information of the same canonical type between business

applications that use different physical data structures; for example, the integration of Project

information between the SAP Project Systems module and the Oracle Primavera application. Both

systems are concerned with the entity “Project”. The basic process for accomplish this utilizes the

information models (LIM, AIM, CIM), and an operation to orchestrate the data flow and execute the

AIMs.

In the diagram below, the basic process flow required for such integration is shown. The diagram is

simplified and elides a number of details for the purpose of clarity.



Figure 1: Simple Integration Process

The second common form for an EPC process adds the complexity of translating data from one canonical

type to another; for example, moving Work Order data from SAP PM into Project data in Oracle

Primavera or Microsoft Project. This requires transformation of Work Order information into Project

information. In the diagram below, the modified process flow for the integration steps is depicted.

Note the addition of the steps that translate the Work Order CIM to the Project CIM. Since this

translation/transformation is done in isolation of the individual back-end systems, non-application

specific business rules could be applied and the transformation reused for other integration processes.

Figure 2: Canonical Translation Process

9.2 Process Example This example will show the data flow and interaction of the various information models and the

Operation steps to make a concrete integration process. The scenario will retrieve information from an

SAP Project and then send this data to Oracle Primavera.

The first step in the process retrieves the desired data from the SAP system using a BAPI call.

• GET Type Step

• Adaptor

• BAPI Call

• SAP PS XML

LIM

• APPLY Type Step

• XSLT/XQUERY/...

AIM • Project Canonical

Model

• Project XML

CIM

• APPLY Type Step

• XSLT/XQUERY/...

AIM • Oracle Primavera

XML

LIM

• SET Type Step

• Adaptor

• Primavera Java API

LIM • Results XML

CIM

• GET Type Step

• Adaptor

• BAPI Call

• SAP PM XML LIM

• APPLY Type Step

• XSLT/XQUERY/...

AIM • Work Order

Canonical Model

• Work Order XML CIM

• APPLY Type Step

• Translate Work Order to Project

• XSLT/XQUERY/...

AIM

• Project Canonical Model

• Project XML

CIM

• APPLY Type Step

• Transform CIM to LIM

AIM • Oracle

Primavera XML

LIM

• SET Type Step

• Adaptor

• Primavera Java API

LIM • Results XML

CIM

•GET

LIM

•APPLY

AIM •Project

CIM

•APPLY

AIM •Primavera

LIM

•SET

LIM •Results

CIM



The information in SAP in this case is certain Project data. SAP users are accustomed to seeing this data

in the SAP application in the context of the user interface:

The data is retrieved by EPC using a Step that specifies a BAPI call as shown in the Operation XML

snippet below.

<Step name="GetSapProjectInfo" type="GET"><IM type="LIM"/>

<Adaptor id="JRAAdaptor" />

<Method name="executeCallAdaptor" />

<Params>

<Param name="bapiName">BAPI_PROJECT_GETINFO</Param>

<Param name="xmlRequest">{BuildSapProjectInfoRequest}</Param>

<Param name="server" />

<Param name="client" />

<Param name="systemNumber" />

</Params>

<Dependencies />

</Step>

The result of the execution of this step during an integration process is a LIM, which can be referred to

by any step in the Operation as the document named “GetSapProjectInfo”, because this is the name of

the Step that generated the LIM. Executing a BAPI call always returns XML in the form specified by the

interface definition for the BAPI, and might look something like the XML snippet below.

<TABLES>

<E_ACTIVITY_TABLE>

<E_MESSAGE_TABLE/>

<E_WBS_ELEMENT_TABLE>

<item>

<WBS_ELEMENT>A-1000</WBS_ELEMENT>

<PROJECT_DEFINITION>A-1000</PROJECT_DEFINITION>

<DESCRIPTION>Sample Project</DESCRIPTION>

</item>

<item>

<WBS_ELEMENT>A-1000-1</WBS_ELEMENT>


<DESCRIPTION>Child WBS Sample</DESCRIPTION>

</item>

</E_WBS_ELEMENT_TABLE>

<E_WBS_HIERARCHIE_TABLE>

<item>

<WBS_ELEMENT>A-1000</WBS_ELEMENT>


<UP/>

<DOWN>A-1000-1</DOWN>

<LEFT/>

<RIGHT/>

</item>

<item>

<WBS_ELEMENT>A-1000-1</WBS_ELEMENT>


<UP>A-1000</UP>

<DOWN/>

<LEFT/>



<RIGHT/>

</item>

. . .

Figure 3: SAP BAPI LIM XML

The next step is to transform this LIM XML into the Project CIM XML.

This is done using an APPLY type Step that applies the logic of an AIM, usually specified in an XSL or

XQUERY document, to the input LIM XML in order to generate the CIM XML. The snippet below shows

an example of a Step from an Operation XML that could be used to specify an AIM Step.


<IM type="AIMXsl">${llx.home}/config/im/sapps/SAPProjectSystemLIMToProjectCIM.xsl</IM>

<Params>

<Param name="inputDoc">{BuildSapInfoCIM}</Param>

</Params>

<Dependencies />

</Step>

The code sample below shows a snippet from an XSL document that provides the logic for transforming

WBS elements into the Project CIM.

<WBSs>

<xsl:apply-templates select=”.//E_WBS_ELEMENT_TABLE/item” mode=”WBS_item”>

<xsl:with-param name=”ProjectId” select=”$ProjectId”/>

</xsl:apply-templates>

<xsl:if test=”PS:mapNetworkToWBS() = ‘true’”>

<xsl:apply-templates select=”//E_NETWORK/item” mode=”NetworkWBS_item”>

<xsl:with-param name=”ProjectId” select=”$ProjectId”/>


</xsl:if>

</WBSs>

<xsl:template match=”item” mode=”WBS_item”>

<xsl:param name=”ProjectId”/>

<xsl:variable name=”SAPWBSId”>

<xsl:value-of select=”WBS_ELEMENT”/>

</xsl:variable>

<xsl:variable name=”P6WBSId”>

<xsl:value-of select=”PS:getP6WBS($ProjectId, $SAPWBSId)”/>

</xsl:variable>

<xsl:variable name=SAPWBSParent”

select=”ancestor::*/E_WBS_HIERARCHIE_TABLE/item[WBS_ELEMENT=$SAPWBSId]/IP”/>

<xsl:variable name=”P6WBSParent” select=”PS::getP6WBS($ProjectId, $SAPWBSParent)”/>

<WBS>

<xsl:attribute name=”GUID”>

<xsl:value-of select=”$P6WBSId”/>

</xsl:attribute>

•GET

LIM

•APPLY

AIM •Project

CIM

•APPLY

AIM •Primavera

LIM

•SET

LIM •Results

CIM



<Name>

<xsl:value-of select=”DESCRIPTION”/>

</Name>

<ParentWBS>

<xsl:value—f select=”$P6WBSParent”/>

</ParentWBS>

<ProjectGUID>

<xsl:value-of select=”$ProjectId”/>

</ProjectGUID>

The results of the above step produce the Project CIM, a snippet from which shows the WBS data

structured into the Project XML.

<WBSs>

<WBS GUID=”A-1000”>

<Name>Sample WBS</Name>

<ParentWBS/>

<ProjectGUID>A-1000</ProjectGUID>

<Status>Active</Status>

<StartDate>2012-07-18 00:00:00</Start Date>

<UDFs/>

<WBSNotes/>

<Activities/>

<WBSs>

<WBS GUID=”-1”>

<Name>Sample Sub WBS</Name>

<ParentWBS/>

<ProjectGUID>A-1000</ProjectGUID>

<Status>Active</Status>

<StartDate>2012-07-18 00:00:00</Start Date>

<UDFs>

<UDF>

<Title>SAP WBS Element </Title>

<Type>Text<Type>

<Value>A-1000</Value>

</UDF>

</UDFs>

. . .

Figure 4: Project XML Snippet with WBS

Next, the Project CIM is transformed into the Oracle Primavera XML format using an AIM step.

A snippet from an Operation XML shows an AIM step definition to transform a Project CIM into Oracle

Primavera XML as a LIM.

<Step name="BuildPrimaveraLIM" type="APPLY">

<IM type="AIMXsl">${llx.home}/config/im/primavera/ProjectCIMToPrimaveraLIM.xsl</IM>

<Params>

<Param name="inputDoc">{BuildProjectCIM}</Param>

</Params>

<Dependencies />

</Step>

•GET

LIM

•APPLY

AIM •Project

CIM

•APPLY

AIM •Primavera

LIM

•SET

LIM •Results

CIM



A snippet of the XSL that might be specified in such a step is shown below, with the snippet again

showing the WBS data transformation.

<xsl:template match=”WBS”>

<xsl:param name=”projectId”/>

<xsl:param name=”projectWBSs”/>

<xsl:variable name=”wbsId” select=”@GUID”/>

<WBSs>

<WBSCode>

<xsl:value-of select=”$wbsId”/>

</WBSCode>

<Name>

<xsl:value-of select=”Name”/>

</Name>

<ProjectId>

<xsl:value-of select=”$projectId”/>

</ProjectId>

<xsl:if text=”fns:chkNotNull(ParentWBS)=’true’”>

<ParentWBS>

<xsl:vaue-of select=”PrarentWBS”/>

</ParentWBS>

</xsl:if>

<xsl:if test=”fns:chkNotNull(Status) = ‘true’”>

<Status>

<xsl:value-of select=”Status”/>

</Status>

</xsl:if>

The output of this step is the project data in the form of the LIM that is expected by the Primavera

adaptor.

<EPS>

<Id>SAPEPS</Id>

<Name>SAPEPS</Name>

<ParentEPSId/>

<Projects>

<Project>

<Id>A-1000</Id>

<Name>Sample Project</Name>

<ParentEPS>SAPEPS</ParentEPS>

<PlannedStartDate>2012-07-18</PlannedStartDate>

<AnticipatedStart>2012-07-18</AnticipatedStartDate>

<AnticipatedFinishDate>2013-04-30</AnticipatedFinishDate>

<ActivityDefaultCalendar>US</ActivityDefaultCalendar>

<ProjectNotes/>

<Codes/>

<WBSs>

<WBS>

<WBSCode>A-1000</WBSCode>

<Name>Sample WBS Node</Name>

<ProjectId>A-1000</ProjectId>

<UDFs>

<UDF>

<Title>SAP WBS Element</Title>

<DataType>Text</DataType>

<Value>A-1000</Value>

</UDF>

. . .

Next, this LIM is input into a SET type Step that calls the Primavera adaptor with the XML data as input.



The adaptor handles transparently all the logic requires for creating or updating the information in the

Primavera application. The snippet below shows an Operation Step definition for performing this work.

<Step name="WritePrimaveraProjects" type="SET">

<IM type="LIM" />

<Adaptor id="PrimaveraAdaptor" />

<Method name="createOrUpdate" />

<Params>

<Param name="dataXml">{BuildPrimaveraLIM}</Param>

<Param name="crudParamsXml">{ReadCrudParamXmlForWrite}</Param>

</Params>

<Dependencies />

</Step>

The final step in this process generates the Results CIM XML that will be returned to the caller of the

Operation service.

It is typical to find such a step at the end of an Operation specification. The XML snippet below shows an

example of Steps that generates a Results CIM. Note that there are actually two steps in this part of the

process, an APPLY Step that takes the return data from the Adaptor call and transforms it to a Result

XML, and the final Step that bundles this into a CIM. By definition, all Operation service calls return only

a CIM.

<Step name="BuildTableResultsCIM" type="APPLY">

<IM type="AIMXsl">${llx.home}/config/im/audit/auditdetail.xsl</IM>

<Params>

<Param name="inputDoc">{WritePrimaveraProjects}</Param>

<Param name="idStr" />

</Params>

<Dependencies>

<Dependency stepName="CheckForErrors" />

</Dependencies>

</Step>


<IM type="AIMXQuery">${llx.home}/config/datapath/im/System/WrapAsCIM.xquery</IM>

<Params>

<Param name="limParam">{BuildTableResultsCIM}</Param>

</Params>

<Dependencies>

<Dependency stepName="BuildTableResultsCIM" />

</Dependencies>

</Step>

•GET

LIM

•APPLY

AIM •Project

CIM

•APPLY

AIM •Primavera

LIM

•SET

LIM •Results

CIM

•GET

LIM

•APPLY

AIM •Project

CIM

•APPLY

AIM •Primavera

LIM

•SET

LIM •Results

CIM



10 Development environment setup

10.1 Development Mode SAP Enterprise Project Connection can be installed in either development mode, or production mode. In

development mode, the configuration and integration implementation files are available on the file

system and can be freely modified by authorized users. Systems that have been installed, or converted

to production mode store the configuration data in the underlying database. It is not intended that the

implementation documents be modified directly on a system configured to production mode.

10.2 Tools and Development Environment It is recommended to have a fully installed SAP EPC development environment available for use before

attempting to pursue the customization of the product. As the product does use primarily XML and Java

technologies for implementation, there are a number of SAP and third party tools available for

utilization as a development environment. The types of tools required include:

XML Editing and Debugging Environment

Interactive HTTP URI construction, calling and response viewing environment

SAP NWDS

In some cases, it may be desired to modify or extend an ABAP RFC or BAPI to add data elements to what

is available in the interface. In this case, the ABAP development skills and an ABAP development

environment will also be required. Modification of RFCs and BAPIs are beyond the scope of this

document.

10.3 Managing Customization Changes It is recommended practice to store any modified implementation files in a location other than the

default location for the template solution. The customary practice is to change the name of the path in

the development environment to include the customer or site name of the implementation. As an

example, if the XSL file, “/home/config/im/wppm/OrderToProject.xsl” needed to be changed for a

customer named Acme, the modified file should be stored in

“/home/config/im/Acme/wppm/OrderToProject.xsl”, and the Operations that reference this XML file

adjusted accordingly.

11 Implementing Custom Mappings Customizations to the product are the result of a gap between the sample solution set and the real-

world business requirements. Therefore, when making changes to the solution, the place to begin is

with the requirement, then to look at how each requirement could be implemented within the product,

while at the same time providing analysis from the perspective of information integration and data



integrity to ensure that no requirement creates a conflict with any of the end-point system’s

configurations or business rules, or with any other data integration requirement.

In this section of the guide, a few commonly seen customization requirements are provided as how-to

type examples for making the requisite changes to the product. The goal of this section is to provide the

understanding of how to go from a requirement to making the changes to the implementation, not to

provide a catalog of changes one could make to their implementation.

11.1 Mapping an SAP Project to an Enterprise Project Structure in Oracle

Primavera In this example, there is a requirement to place data coming from the SAP Project Systems module into

a specific Enterprise Project Structure (EPS) in Oracle Primavera. All projects stored in Primavera must

belong to an EPS node, and which node a project belongs to has implications for which Primavera users

will be able to see and interact with the project in Primavera, along with other considerations specific to

the Oracle Primavera functionality.

The requirement for this example states:

Any project being transferred for the first time from SAP PS to Oracle Primavera shall be placed

into an EPS Node based on the contents of the SAP Project Profile data field in the Project. In the

case where the requisite EPS Node does not exist within Primavera, the product shall not

attempt to create the EPS Node, but shall place the project into a designated default EPS Node

named “SAPEPS”.

In order to create an implementation that satisfies this requirement, the following tasks will be

performed:

Modify an Operation

Modify an XSL document that controls mapping from LIM to CIM

Create a custom XSL function and add it to the XSL function library

Extend the solution configuration file to add the customized mapping table

For this requirement, one is able to determine that the integration flow affected is the one that sends

data from SAP PS to Oracle Primavera. To find the Operation that governs this flow, one must access the

development installation’s file system and look into the “<install location>/config/operations” folder to

find the file that contains the appropriate Operations. A file named something like “sapps_saptop6-

operations.xml” is likely the correct file. Note however, that if the system has previously been

customized, the file may be called something different, and locally created documentation should

provide the name of the file desired. Once the correct file has been located, open the file to view the

Operations and Operation definitions contained therein. The graphic below provides an example from a

customized Operations file to show the types of Operations one might see.



Note that one of the Operation names is “SAPToP3eProjectSync”. This name suggests that it contains

the instructions for transferring project data from SAP PS to Oracle Primavera and is a good place to

begin.

The correct place within the Information Architecture to begin making the required change is the AIM

that controls how data is translated between the SAP PS LIM and the Project CIM. Looking into the

“SAPToP3eProjectSync” Operation, there are a number of steps, one of which is named

“BuildProjectCIM”. The graphic below shows a snippet of the “SAPToP3eProjectSync” Operation with

the “BuildProjectCIM” step. Note that the “BuildProjectCIM” step references the XSL file,

“SAPProjectSystemLIMToProjectCIM.xsl”. From this information, one can determine that the place to

make the requisite change will be in this XSL file.

Note also that the “BuildProjectCIM” Step takes as input an XML document that is generated by the Step

“BuildSapInfoCIM”, which appears to combine XML documents from “GetSapProjectInfo” and



“GetSapNetworkInfo”, which in turn appear to be produced by BAPI calls. This should be noted as it may

be required to reference the LIMs from these interfaces as part of the modifications to be made.

Looking at the XSL in this file, one can see that the default logic is quite straight forward, simply placing

any Project from SAP PS into an EPS Node named “SAPEPS”. The snippet below shows the requisite

section of the XSL document that performs this work.

…

<xsl:template name=”EPS”>

<EPS>

<xsl:attribute name="GUID">

<xsl:text>SAPEPS</xsl:text>

</xsl:attribute>

<Name>


</Name>

<ParentEPS/>

</EPS>

</xsl:template>

…

The requirement however, requires that the EPS for the Project be determined by the value of the SAP

Project Profile field, so this XSL must be modified to implement the correct mapping. One way this could

be accomplished might look like the code snippet below. The overall structure of the snippet is as

follows: variable definition, mapping lookup, mapping logic, default assignment.

In the variable definition portion:

<xsl:variable name="ProjProfile">

<xsl:value-of select=".//E_PROJECT_DEFINITION/PROJECT_PROFILE" />

</xsl:variable>

A variable named “ProjProfile” is created and populated from the XML Path,

“.//E_PROJECT_DEFINITION/PROJECT_PROFILE”. This XML path can be found as part of the LIM that was

made available to this Step from the “BuildSAPInfoCIM” step in the Operation.

In the next statement:

<xsl:value-of select="PS:getP6EPSNode($ProjProfile)" />

An external XSL function named PS:getP6EPSNode is called with the value of the “ProjProfile” variable.

For now, it is enough to know that the implementation of this function returns the value of the correct

EPS node given a valid SAP Project Profile, and a zero length string in all other cases.

This is followed by some XSL logic that either maps the non-zero length string value returned from the

XSL function, or assigns the default node if the lookup was unsuccessful.

Here is the snippet in its entirety.

…

<xsl:template name="EPS">

<xsl:variable name="ProjProfile">



<xsl:value-of select=".//E_PROJECT_DEFINITION/PROJECT_PROFILE" />

</xsl:variable>


<xsl:choose>

<xsl:when test="string-length(PS:getP6EPSNode($ProjProfile))>0">

<EPS>

<xsl:attribute name="GUID">


</xsl:attribute>

<Name>

<xsl:value-of select="PS:getP6EPSDescription($ProjProfile)" />

</Name>

<ParentEPS />

</EPS>

</xsl:when>

<xsl:otherwise>

<EPS>

<Name>


</Name>

<ParentEPS />

</EPS>

</xsl:otherwise>

</xsl:choose>

</xsl:template>

…

Rather than saving these changes over the default XSL file, it is considered a better practice to save a

copy of the file to a customer specific folder in the configuration, and then modify the path specified in

the Operation step to refer to the new file. In this manner, it is possible to revert the system to the

default configuration if necessary. For example, in the Operation document, the Step “BulidProjectCIM”

would be modified from (changed area highlighted in yellow):


<IM type="AIMXsl">${llx.home}/config/im/sapps/SAPProjectSystemLIMToProjectCIM.xsl</IM>

<Params>


</Params>

<Dependencies />

</Step>

to:


<IM type="AIMXsl">${llx.home}/config/im/Acme/sapps/SAPProjectSystemLIMToProjectCIM.xsl</IM>

<Params>


</Params>

<Dependencies />

</Step>

Now it is time to consider what the PS:getP6EPSNode function does, and how the actual lookup and

translation from SAP Project Profile to Primavera EPS is performed. In this example, the approach is to

maintain an XML lookup structure in the WPPSConfiguration.xml configuration document (see the EPC

Installation Guide for more information about this document). Because the document is XML, one can

add new elements and nodes to it as needed. In this case, the implementer adds and <EPS> node to the

document along with the translation values to be used. It should be noted that this is only one of several

ways that this type of functionality could be implemented and was chosen here to keep the example



content straight-forward and without introducing undue complexity. The XML snippet below shows how

this might look in the WPPSConfiguration.xml file:

…

<EPS>

<Node>

<SAPProjProfile>Profile A</SAPProjProfile>

<SAPDescription>Profile A Type Projects</SAPDescription>

<P6EPSNode>SAP-EPS-Profile-A</P6EpsNode>

<Node>

<Node>

<SAPProjProfile>Profile B</SAPProjProfile>

<SAPDescription>Profile B Type Projects</SAPDescription>

<P6EPSNode>SAP-EPS-Profile-B</P6EpsNode>

<Node>

</EPS>

…

Note that this creates a requirement that the WPPSConfiguration.xml file be manually maintained by a

system administrator as SAP Project Profiles and/or Oracle Primavera EPS structures are added,

modified, or removed.

The WPPSConfiguration.xml document was chosen for this implementation as it is already referenced

from the PSProject-Functions.xsl document, which is the document used to store the XSL functions

specific to processing for this solution. This can be determined by examining the PSProject-Functions.xsl

document and observing the line of XSL:

<xsl:variable name="PSConfig" select="document('WPPSConfiguration.xml')" />

It would also have been possible to generate a new XML configuration file and include the reference to

that new file from the PSProject-Functions.xsl file. For example, one could have stored the EPS mapping

XML in a document named: AcmeConfiguration.xml, and then added the following line to the PSProject-

Functions.xsl file:

<xsl:variable name="AcmeConfig" select="document('AcmeConfiguration.xml')" />

Now the PSProject-Functions.xsl document needs to have the custom XSL functions PS:getP6EPSNode,

and P6:getP6EPSDescription added to it. The implementation for these functions is straight forward and

consists of only a few lines of XSL to lookup the corresponding EPS Node value given a SAP Project

Profile:

<xsl:function name="PS:getP6EPSNode">

<xsl:param name="SAPProjProfile" />

<xsl:value-of select="$PSConfig//EPS/Node[SAPProjProfile=$SAPProjProfile]/P6EPSNode" />

</xsl:function>

- <xsl:function name="PS:getP6EPSDescription">

<xsl:param name="SAPProjProfile" />

<xsl:value-of select="$PSConfig//EPS/Node[SAPProjProfile=$SAPProjProfile]/SAPDescription" />

</xsl:function>



11.2 Mapping an SAP Work Order to an Oracle Primavera Project In this example, there is a requirement to place Work Order data coming from the SAP Plant

Maintenance module into specific Projects in Oracle Primavera based on the SAP WBS information. The

template solution utilizes data fields from the SAP Work Order Header to determine which Project in

Oracle Primavera a Work Order is transformed into, so the mapping logic needs to be modified to

accomplish the requirement.


Any Work Order Operation being transferred for the first time from SAP PM to Oracle Primavera

shall be placed into a Project based on the contents of the SAP WBS Element data field in the

Work Order. In the case where the requisite Project does not exist within Primavera, the

product shall automatically create the Project and populate the Work Order data into the

Project accordingly.


performed:

Modify an Operation

Modify an XSL document that controls the mapping from LIM to CIM

Create new XSL variables and add them to the XSL document


data from SAP PM to Oracle Primavera. To find the Operation that governs this flow, one must access

the development installation’s file system and look into the “<install

location>/config/datapath/operations” folder to find the file that contains the appropriate Operations. A

file named something like “sappm_saptop6-operations.xml” is likely the correct file. Note however, that

if the system has previously been customized, the file may be called something different, and locally

created documentation should provide the name of the file desired. Once the correct file has been

located, open the file to view the Operations and Operation definitions contained therein. The graphic

below provides an example from a customized Operations file to show the types of Operations one

might see.

<Operations xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:noNameSpaceSchemaLocation=”Operations.xsd” version=”1.0” namespace=”core”>

<Operation name=”SAPtoP6” cache=”false”>

. . .

</Operation>

<Operation name=”SAPtoP6Controller” cache=”false”>

. . .

</Operation>

</Operations>

http://www.w3.org/2001/XMLSchema-instance



Note that one of the Operation names is “SAPtoP6”. This name suggests that it contains the instructions

for transferring project data from SAP PM to Oracle Primavera and is a good place to begin.



“SAPtoP6” Operation, there are a number of steps, one of which is named “BuildProjectCIM”. The

graphic below shows a snippet of the “SAPtoP6” Operation with the “BuildProjectCIM” step. Note that

the “BuildProjectCIM” step references the XSL file, “ OrderToProject.xsl”. From this information, one can

determine that the place to make the requisite change will be in this XSL file.


“BuildOrdersCIM”, which appears to combine XML documents from “GetOrdersFromSAP”, which in turn

appears to be produced by a BAPI call. This should be noted as it may be required to reference the LIMs

from these interfaces as part of the modifications to be made.

Looking into the “OrderToProject.xsl” file, one can see that the <ProjectCIM> is generated via the use of

XSL templates, and specifically, that the mapping of Work Orders to Projects is performed by logic

contained in the templates “OrderTypes” and “Projects”.

The “OrderTypes” template generates a distinct set of Work Orders based on the criteria in the XSL

mappings in the template.

The “Project” template then uses this information to construct Project entities, and map the Work Order

data into each project according to the Work Order type. The snippet below shows a portion of the XSL

in the Project template.

<xsl:template name=”Project”>

<xsl:param name=”ordersByType”/>

<xsl:variable name=”ordersVar” select=”//Order”/>



<xsl:for-each select=”distinct-values($ordersByType/WorkOrders/Order/ProjectId)”>

<xsl:variable name=”projectId” select=”.”/>

<Project>



</xsl:attribute>

<Name>


</Name>

<ParentEPS>

<xsl:value-of select=”$ordersByType/WorkOrders/Order[ProjectId =

$projectId[1]/EPSNode”/>

</ParentEPS>

<Activities>

<xsl:for-each select=”$ordersByType/WorkOrders/Order[ProjectId = $projectId]”>

<xsl:variable name=”currentOrderNode” select=”.”/>

<!—get order details for the current ordered -->

<xsl:variable name=”orderNode” select=”$ordersVar[@id = $currentOrderNode/OrderId]

/>

<xsl:apply-templates select=”$orderNode” mode=”Activity”>

<xsl:with-param name=”orderType”>

<xsl:value-of select=”$currentOrderNode/OrderId/@type/>

</xsl:with-param>


</xsl:for-each>

</Activities>

Observe that Work Order data is being assigned to each Project according to the selection criteria. Each

of the Work Order Operations found in the “ordersByType” parameter (which was populated by the

Orders template) must be mapped to a Project. The template solution uses the Work Order Operation Id

(assigned to the variable $projectId).



The requirement for this example is to map Order data to Projects based on the top level of the SAP

Work Order Header WBS Element. To accomplish this, the Order CIM must be referenced to obtain the

value, and then this value mapped into the Project CIM being created in the Projects template where

$projectId is currently being used.

In this example, the SAP system has been configured such that the WBS structure has 7 alphanumeric

characters, followed by a single digit for each level below, delimited by a period. An example of an SAP

WBS Element value one might find in this context could be, “A-10105.1.1.1.0”. Because of this, the logic

in the modified XSL will need to parse the SAP WBS Element to obtain just the “A-10105” portion to use

as the Project Id in the Project CIM.

To accomplish this, create two global variables in the XSL document, above all the templates:

<xsl:variable name=”SAPWBSId” select=”distinct-values(//SAP_WBSELEMENT)”/>

<xsl:variable name=”customProjectId” select=”substring($SAPWBSId, 1, 7)”/>

The first variable gets the ID of the WBS Element from the Order CIM, and the second parses out the

portion of the WBS that is required to manufacture the desired Project Id.

Next, the XSL within the Projects template must be modified to use the new “customProjectId” and map

this to the GUID attribute and the Name element of the Project element in the Project CIM.

<xsl:for-each select=”distinctvalues($ordersByType/WorkOrders/Order/ProjectId)”>

<xsl:variable name=”projectId” select=”.”/>

<Project>


<xsl:value-of select=”$customProjectId”/>

</xsl:attribute>

<Name>

<xsl:value-of select=”$customProjectId”/>

</Name>

…

With these changes, the Order Operations will now be mapped to Projects based on the top level WBS

data from SAP.

11.3 Mapping an SAP Work Order to an Enterprise Project Structure in Oracle

Primavera In this example, there is a requirement to place data coming from the SAP Project Maintenance module

into a specific Enterprise Project Structure (EPS) in Oracle Primavera. All projects stored in Primavera

must belong to an EPS node, and which node a project belongs to has implications for which Primavera

users will be able to see and interact with the project in Primavera, along with other considerations

specific to the Oracle Primavera functionality.


Any Work Order being transferred for the first time from SAP PM to Oracle Primavera shall be

placed into an EPS Node based on the contents of the SAP Main Work Center (MN_WK_CTR)

data field in the Project.


performed:

Modify an Operation

Modify an XSL document that controls mapping from LIM to CIM


data from SAP PM to Oracle Primavera. To find the Operation that governs this flow, one must access

the development installation’s file system and look into the “<install

location>/config/datapath/operations” folder to find the file that contains the appropriate Operations. A

file named something like “sappm_saptop6-operations.xml” is likely the correct file. Note however, that

if the system has previously been customized, the file may be called something different, and locally

created documentation should provide the name of the file desired. Once the correct file has been

located, open the file to view the Operations and Operation definitions contained therein. The graphic

below provides an example from a customized Operations file to show the types of Operations one

might see.

<?xml version=”1.0” encoding=”UTF-8” ?>



<Operations xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance

xsi:noNameSpaceSchemaLocation=”Operations.xsd” version=”1.0” namespace=”core”>

<Operation name=”SAPtoP6” cache=”false”>

. . .

</Operation>

<Operation name=”SAPtoP6Controller” cache=”false”>

. . .

</Operation>

</Operations>

Note that one of the Operation names is “SAPtoP6”. This name suggests that it contains the instructions

for transferring project data from SAP PM to Oracle Primavera and is a good place to begin.



“SAPtoP6” Operation, there are a number of steps, one of which is named “BuildProjectCIM”. The

graphic below shows a snippet of the “SAPtoP6” Operation with the “BuildProjectCIM” step. Note that

the “BuildProjectCIM” step references the XSL file, “ OrderToProject.xsl”. From this information, one can

determine that the place to make the requisite change will be in this XSL file.

<Step name=”GetOrdersFromSAP” type=”GET”>

<IM type=”LIM/>

http://www.w3.org/2001/XMLSchema-instance



<Adaptor id=”JRAAdaptor” />

<Method name=”executeCallAdaptor” />

<Params>

<Param name=”bapiName?”>/SEPC/PLMA_ALM_ORDER_GET_DET</Param>

<Param name=”xmlRequest”>{BuildRequestsFromOrderIds}</Param>

<Param name=”server” />

<Param name=”client” />

<Param name=”systemNumber” />

</Params>

<Dependencies/>

</Step>

<Step name=”BuildOrdersCIM” type=”APPLY”>

<IM type=”AIMXsl”>${llx.home}/config/im/sappm/OrdersLIMToOrdersCIM.xsl</IM>

<Params>

<Param name=”inputDoc”>{GetOrdersFromSAP}</Param>

<Param name=”operationIds”/>

</Params>

<Dependencies />

</Step>


“BuildOrdersCIM”, which appears to combine XML documents from “GetOrdersFromSAP”, which in turn

appears to be produced by a BAPI call. This should be noted as it may be required to reference the LIMs

from these interfaces as part of the modifications to be made.

Looking at the XSL in this file, one can see that the default logic is quite straight forward, simply placing

any mapping the value of the XML Path “//MN_WK_CTR” into the EPS. The snippet below shows the

requisite section of the XSL document that performs this work.

<xsl:template match=”/”>

<ProjectCIM>

<EPSs>

<xsl:for-each select=”distinct-values(//MN_WK_CTR)”>

<xsl:variable name=”mainWorkCenter” select=”.”/>

<EPS>


<xsl:value-of select=”$mainWorkCenter” />

</xsl:attribute>

<Name>

<xsl:value-of select=”$mainWorkCenter” />

</Name>

<ParentEPS />

</EPS>

<xsl:for-each>

</EPSs>

12 Customizing Java Adaptor Rules The adaptor that provides the Oracle Primavera interface is based on a rules-controlled java adaptor

framework. From EPC 2.0 version, it is possible to customize the behavior of the adaptor through the

development and publishing of custom rules that will take the place of the default set of rules that ship

with the adaptor. These rules take the form of CRUD (Create, Read, Update, and Delete) rules that have

been instrumented within the core adaptor with event handlers that can be modified.

This type of customization requires Java programming knowledge, and familiarity with the SAP NWDS.

An understanding of Oracle Primavera project data and handling is also desirable.



12.1 Project setup in NWDS Modification of the adaptor rule-set requires establishing a Java project in the NWDS environment.

1. Open NWDS and launch the New Project Wizard.

2. Select Development Infrastructure->Development Component.

3. Select a Project of Type sap.com->Java.



4. In Development Infrastructure perspective, import ENTERPRISEPROJECTCONNECTION.sca



5. The imported SC should be added as a dependency to the SC that you are working on.

6. Select DC and add the following dependencies from ENTERPRISE_PROJECT_CONNECTION. Go to Component Properties, click on Add. Expand ENTERPRISE_PROJECT_CONNECTION and add the following DCs.

xapps/epc/common xapps/epc/crudadaptor xapps/epc/crudadaptor-shared xapps/epc/crudadaptorjavacontrollers xapps/epc/p6adaptor

The DC is now setup for developing CRUD rule classes.



12.2 CRUD Rules Implementation The java classes for handling the business rules for Primavera integration should follow the following

rules.

1. Rules package root must be a. com.laborlogix.primavera.rule.read for read b. com.laborlogix.primavera.rule.write for write c. com.laborlogix.primavera.rule.delete for delete

2. Only the last folder in the package structure can have any name and must be specified in CrudParameters xml

<CrudParameter GUID="WriteRuleSetFilter">

<Name>WriteRuleSetFilter</Name>

<Value>activitydetails</Value>

</CrudParameter>

The xml should be loaded in the operation steps and passed to P6Adaptor.

Here, the name is set as per the operation type ReadRuleSetFilter, WriteRuleSetFilter or

DeleteRuleSetFilter. Value is the last folder in the package name.

3. The Rule class name should start with “Llx” + primavera object name with “Rule” appended in the end. For e.g.: LlxActivityRule

4. The Rule class should be extended from com.laborlogix.datapath.adaptor.crud.controller.event.BaseJavaRuleCrudEventHandler.

5. The methods in the class BaseJavaRuleCrudEventHandler shall be overridden to add CRUD rules. The event processing can be done in three ways. For example, for write operation, pre-

processing can be done in the handleInitWriteEvent method. Rules at the time of read can be

applied through handleWriteEvent and post-processing in handlePostWriteChildrenEvent.

6. To create the jar file, select the DC and select Export from the context menu. Select Java-> jar

file. Select src and Export generated class files and resources checkbox.



Example for the eventhandler code is shown below:

package com.laborlogix.primavera.rule.write.activity; import com.laborlogix.datapath.adaptor.crud.NodeProcessingInstructions; import com.laborlogix.datapath.adaptor.crud.controller.event.BaseJavaRuleCrudEventHandler; import com.laborlogix.datapath.adaptor.crud.controller.event.CrudEvent; public class LlxActivityRule extends BaseJavaRuleCrudEventHandler { @Override public NodeProcessingInstructions handleInitWriteEvent(CrudEvent event) { // TODO Auto-generated method stub return super.handleInitWriteEvent(event); } @Override public NodeProcessingInstructions handlePostWriteChildrenEvent( CrudEvent event) { return super.handlePostWriteChildrenEvent(event); } @Override public NodeProcessingInstructions handleWriteEvent(CrudEvent event) { return super.handleWriteEvent(event); } }



12.3 Importing New Rules The java CRUD rules jar file can be imported into EPC using EPC CTC scenarios by the Admin user.

1. Login to nwa using a user with datapath-rest access

2. Go to Configuration-> Scenarios -> Configuration Wizard

3. Execute the task SAP Enterprise Project Connection (EPC) End User Scenarios

4. From the Configuration Setup, select Upload/Replace Oracle Primavera CRUD Java Rules

5. Choose Upload A Customized Java Rule Jar File

6. Enter the jar file path and Finish the scenario.

integration solution development guide - news - … basic understanding of key fields in projects;...

Documents