Overview
Open Interfaces play a very important role in the area of Product Lifecycle Management. Modern designs involve IT-support in the area of mechanical design, electrical / software development, all type of simulations and much more. With regards to the wide area of integration this blog distinguishes between asynchronous server-to-server scenarios and synchronous user-centric scenarios – even if there is a certain overlap in between.
Server to Server communication is required to exchange information between two (or more) systems in an asynchronous mode. Example for this would be a Material Master which is getting copied from a non-SAP Team Data Management System over to the SAP PLM System once its status was set to ‘released’. Typically SOAP or textual formats like ASCII or XML files are used for these asynchronous scenarios.
Opening SAP PLM for synchronous user centric scenarios has different reasons:
- Beautification of the User Experience: Providing mobile or user-interfaces optimized for specific use-cases based on SAP PLM – using e.g. Microsoft Office or Microsoft SharePoint, HTML5 or native mobile user interfaces.
- Mashing-Up data from various systems: Bringing information from various systems together in one user-interface
- Integration: Allowing other systems to access an SAP System via REST-based APIs to query e.g. the status of a material from another system
This blog covers the synchronous user-centric scenarios that are covered with SAP Gateway. Asynchronous scenarios are covered with other technologies like SAP Process Orchestration (http://scn.sap.com/community/process-orchestration) or the cloud based HANA Cloud Integration (http://scn.sap.com/community/hana-in-memory/blog/2013/10/22/hana-cloud-integration-getting-started).
SAP Gateway
Via SAP Gateway it is possible to add RESTful APIs in the open format of OData to the existing SAP Business Suite / SAP PLM with little effort. Various ways to create the OData Services are supported by SAP Gateway:
- Code-free generation of the OData Services based on existing Remote Function Calls (RFCs) done via mapping in the Gateway Service Builder (Transaction SEGW)
- Manual development by re-definition of methods provided by SAP Gateway super-classes for the required methods like query, read, update or delete.
- Code-free generation of the OData Service based on existing object-oriented implementation of the business object like e.g. Material Master or Engineering Change Record. In the SAP PLM context the business objects were developed by SAP using the SPI-framework (http://wiki.scn.sap.com/wiki/display/SPI/Home;jsessionid=24F422E24DF42AAD8D7037821D1B940F)
Required components, Service Packs and Notes
When looking at e.g. the implementation of the Material Master we have to differentiate two things. One topic is the functionality of the generic
framework that was used in order to implement the service – the SPI framework. In addition the second part is also important – the way how the Material Master got implemented in the SPI Framework.
SAP Gateway is already supporting the SPI framework since the Service Pack 4 of SAP Gateway. All features of the SPI framework were supported (query, read, update, delete …). Unfortunately the implementation of many SAP PLM objects did not support Query and Update methods of the SPI framework. Reason was that these objects were developed optimized for the Floorplan Manager and WebDynpro ABAP. So Enterprise Search and state-full communication were available in the WebDynpro-based user interfaces which meant that there was no need to implement this two features in the underlying SPI service.
As OData is becoming more and more popular now the ability to query was added to the implementation of many SAP PLM objects via Service Packs and / or notes. This makes the development of OData-based applications much more easy – no need to manually program the search. The possibility of updating the SAP PLM objects is not available.
These enhancements will add the possibility to query via OData services to the following SAP PLM objects:
- Material Master (PLM_MAT)
- Document Info Record – SAP DMS (PLM_DIR)
- Engineering Change Record (PLM_ECR)
- Engineering Change Number (PLM_ECN)
So overall with the installation of the right Service Packs for your components you will save a lot of manual effort. Once all the required enhancements are in the system you are ready to go and you can start generating OData services.
Generating an OData Service for the Material Master
SAP Gateway Service Builder
This blog from Ashish is already describing the process of creating an OData Service based on an SPI Object very nicely: http://scn.sap.com/community/gateway/blog/2012/11/27/how-to-create-sap-netweaver-gateway-service-for-spi . So this blog will not go to all details, but will highlight the generation process especially for the Material Master from SAP PLM via the transaction SAP NetWeaver Gateway Service Builder (Transaction SEGW).
First a new project has to be created. A click to the context menu of the Data Model is then allowing redefining an SPI Service. For accessing the Material Master, the technical name of the Material Master (PLM_MAT) has to be selected from the SAP PLM System. This SAP PLM system could be the same system as the SAP Gateway system, it also could be another system communicating to the stand-alone SAP Gateway system via Remote Function Calls (RFCs).
The Material Master is a very central element of SAP ERP and SAP PLM. So there are a lot of attributes to support all the various aspects of central master data. Typically in a mobile scenario not all of the many 100eds of attributes are required. A reduction of the transferred data from the backend to the client
will also reduce the required bandwidth and will improve with this of course performance.
Let us assume that in this small example only the following five attributes will be required in the new user interface:
- Material Number (Key)
- Description
- Base Unit
- Volume
- Industry Sector
These attributes can easily be selected in the wizard that appears in the BASIC_DATA Entity Type. Unfortunately the generated names will be very technical. So a manual change to a more readable notation is required. This can be done in the Service Builder by the Redefinition of Attributes.
Once this manual activity is done the service can be generated.
Activating
Directly from the SAP Gateway Service Builder transaction the Service can now also be published from the backend to the central Gateway Server. Once this is done we are already ready for the last step – the testing of the service.
Testing of the service and examples
For a simple ‘smoke test’ we can use a query that will return two random Material Masters in a JSON format. The perfect transaction for this would be the ‘SAP NetWeaver Gateway Client’ transaction (/IWFND/GW_CLIENT). Here we can enter this query string:
http://server_name:port/sap/opu/odata/sap/Z_MAT_MASTER_SRV/BASIC_DATACollection?$top=2&$format=json
And as a result we receive the details from the backend system in JSON format:
As a next step you will see a list of more realistic examples for queries that are already supported out-of-the box without manual coding. Filtering for a special Material Number could be done in two ways, via a $filter statement or directly as a key (the Material Number is the key field of this service):
- http://name:port/sap/opu/odata/sap/Z_MAT_MASTER_SRV/BASIC_DATACollection?$filter=MaterialNumber eq ‘P-100’
- http://name:port/sap/opu/odata/sap/Z_MAT_MASTER_SRV/BASIC_DATACollection('P-100')
Filtering is also supported for other attributes like the material description:
http://name:port/sap/opu/odata/sap/Z_MAT_MASTER_SRV/BASIC_DATACollection?$filter=MatShortTxt eq ‘Pump’ is now returning a list of all Materials that have the short text ‘Pump’ assigned. Only a more complex queries could result into a full table scan – so please make sure to test the created service upfront. Example for a query that is taking very long would be:
http://name:port/sap/opu/odata/sap/Z_MAT_MASTER_SRV/BASIC_DATACollection?$filter=substringof (‘Pump’, MatShortTxt) eq true
One of the advantages when using SAP Gateway is the very convenient way to log and trace errors or to get an information about the performance behavior via the Gateway Tracing Tools (Transaction /IWFND/TRACES).
Performance Traces, Payload Traces or Error Logs provide a variety of additional information helping to optimize the implementation or identify errors.
Summary
In this blog I wanted to explain how easy it now is to get an OData Service generated with the enhancements provided with the latest Service Packs of SAP PLM. The master data managed by SAP PLM is very often a required piece of information for follow-on processes. The opening up of SAP PLM is now helping to bring the data easily in other environments.
Appendix
The table below provides an overview which SP has to be added as a minimum to add the query possibility to the system. The enhancements are also available as notes – please note that some notes require additional manual steps for the implementation. This list also is the maximum number of notes – depending on your SP-level there could be much less notes requires. The SP5 of IW_SPI is part of SAP Gateway SP9.
Detailed list of Notes:
1728963 Support Package queries are missing.
1913499 Access to the data of a node by means of association
1953183 Failure of SPI Service Generation
1992454 SPI OData Services with Query Options like $top and $skip Do Not Work in HUB scenario
1992501 $filter and $top is Returning Only Keys in the Query Response for SPI
1996130 Duplicate Records while calling Material SPI Query
2007909 Downport of START_ROW parameter
2010845 Disabling NAVI Parameter in SPI
1891137 SPI: $select Based Optimization for Query/Read