DataXstream Virtualizes Lumber Liquidators’ SAP Landscape
Virtualization Project OverviewDataXstream LLC and Lumber Liquidators have announced a business relationship in which Lumber Liquidators has purchased a completely virtualized SAP platform from DataXstream built on VMware and Dell EqualLogic. Lumber Liquidators’ SAP NeedsLumber Liquidators acquired SAP to automate all their back-office processes. Prior to implementation, they were instructed to deploy a hardware platform that would support not only the initial implementation, but incremental growth for the next 3 years. As a new implementation, they were also concerned with minimizing total project cost, delivering high availability and consistent performance to an unknown number of users, and be easily maintainable by a streamlined IT staff. SAP Virtualization SolutionLumber Liquidators turned to DataXstream, an SAP professional services organization focused on technical consulting and integration, with particular skills in landscape design and implementation. After reviewing the business requirements and technical constraints, DataXstream proposed, and then deployed a completely virtualized SAP environment, covering Development, Quality Assurance, and Production landscapes. The resultant solution exceeded the needs requested by Lumber Liquidators:
|
|
- Leveraging DataXstream’s longstanding expertise in SAP, the solution was tuned specifically to support current SAP needs, while remaining flexible enough to grow incrementally as new deployment phases started.
- Utilizing VMware features such as DRS, SRM, and HA, the solution insured consistent SAP response to users, even during scheduled maintenance, or fail-over conditions.
As a result of working with DataXstream, Lumber Liquidators met their implementation timelines, budgetary forecasts, and improved the chance of adoption by its user community. Simultaneously the choice enabled its IT team to easily support the landscape without having to add more resources.
21 Things to Remember for Your Next SAP Upgrade
Is it time for your company to consider an SAP Upgrade?
The choice to upgrade your company’s SAP platform is a very important business decision. Many criteria need to be considered when determining if an SAP upgrade is the right move and, if so, what type of upgrade needs to take place (ECC 6.0, Enhancement Packs, etc.). A successful SAP upgrade requires the determination of your upgrade requirements, proper planning, and an assessment of technical and functional risk. Below is a sample of our SAP Upgrade Checklist white paper:
Determine Your Upgrade Requirements
- What are the business reasons for upgrading? Support from the business for an upgrade project is most important. If there are no business reasons for upgrading, then you should probably not do it. Included here are the business risks incurred by not upgrading.
- What are the technical reasons for upgrading? Included here are the technical risks incurred by not upgrading. (Posture increasing maintenance fees for old versions or complete support withdrawal as a business risk – not a technical risk.)
For the complete list, download the full white paper:
SAP Upgrade Checklist
Related Links:
What’s in a Namespace?
Introduction
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We have built and packaged these solutions both in our own SAP landscape and in our client’s SAP landscape. In doing so, we must be careful about how we manage our namespaces, their associated development and repair license keys, and packages. It is not surprising, then, that I have received several inquiries asking about our namespace strategy for the development, packaging, and distribution of add-on products.
SAP Upgrade Project Management Considerations
This is the first in a series of posts that I will write regarding upgrading your SAP system. 2010 is anticipated as the year of the upgrade (you heard it here first – maybe not) as many SAP customers saw an upgrade as an easily avoidable expense in the midst of the economic carnage of the last 12-18 months. Also, SAP is on a push to get customers off earlier releases and up to ECC 6.0 and various EHP (enhancement packs) to make upgrades a thing of the past.
Excuse a note of skepticism about the end-of-upgrades-as-we-know-them, I suspect the path and the mechanism to get new functionality will change. The text book methodology and approach will change, but I suspect SAP customers will be hesitant to let go completely of previous approaches to upgrades. Sounds like a topic for a future blog post.
In these posts I’ll address some of the upfront considerations before you embark on an upgrade, then progress on to ways to leverage some of your existing assets to make the process as successful as possible. Along the way I’ll discuss the impact on your SAP landscape, non-SAP systems, and other ongoing projects you may have in motion. As a wise man I once worked for said–and I’m paraphrasing–“we don’t want to rebuild the plane in midair.” Trying to get it in the hangar without passengers onboard is a noble goal, but perhaps not completely realistic.
This discussion is pitched at a fairly high level although an in depth discussion is easily set up by clicking here to contact us.
For more on SAP Upgrades download the white papers:
SAP Upgrade Checklist
Customization Risk Analysis in an SAP Upgrade Project
As always, comments and feedback are welcome, but I ask you to be civil. Your experiences are not the same as mine, I can learn from you and I hope you can learn a little from me. Let’s begin.
Read more
Build an SAP IDOC Receiver Using the SAP .Net Connector
Overview
This blog post describes how to receive an IDOC from an SAP system, using the SAP .Net Connector and Microsoft C#.
Introduction
The SAP .Net Connector simplifies creating C# programs that can interoperate with an SAP host. The SAP .Net Connector is available from the SAP Service Marketplace. You must have access to the SAP Service Marketplace to be able to download the SAP .Net Connector. The SAP .Net Connector must be installed on your development machine before we begin.
An IDOC is an Interface Document that is used to send or receive information to or from an SAP host. An IDOC will consist of a header record and as many detail records as necessary. The header records follow the format of the EDI_DC40 table, and the detail records follow the format of the EDI_DD40 table. The exact format of the payload in the detail records depends on the type of IDOC being transmitted.
Read more
DataXstream Workflow Troubleshooting Guide
By: Thomas Nittmann
Description: This article focuses on practical techniques used to assist in the debugging and resolving workflow issues during the development and production support phases of SAP implementations. The SAP Workflow application incorporates the use of several components, i.e. graphical editing tool (workflow builder), some object orientated concepts (use of the Business Object Repository), ABAP, and a hook/trigger mechanism into one of the SAP application modules (FI, CO, MM, etc). As business requirements are mapped into a workflow process definition and prototyping starts, debugging becomes an essential tool to expedite the implementation of workflow process.
To read more about SAP Workflow Troubleshooting please download the whitepaper here or simply click on the “Learn More” tab to the right to request this and other DataXstream white papers.
Q2Q3Y6XJM37U
SAP Integration Optimization
In any SAP implementation, there are a multitude of tasks and specialties happening all at once in preparation for Go-Live. Priority tasks such as business blue-printing and SAP core module configuration (FI/CO, MM, SD, etc.) take precedence over integration technologies such as ALE, XI/PI, and IDocs, as these are widely viewed as the “plumbing” of the SAP landscape. This SAP “plumbing” is needed, but “hidden in the walls” of the ERP system, and is rarely architected and managed at an Enterprise level. In larger ERP implementations, it’s very common for different groups to integrate to various systems independently and without regard to what other teams are doing. Legacy technologies may be incorporated as quick fixes, with plans to decommission later. Some teams may use a custom point-to-point integration approach, other teams will utilize IDocs, others will send messages to XI/PI via BAPI’s, and others may customize standard interfaces or use flat files.
After the system goes live, there may be a time period of stabilization, with a frantic scramble to make the system operational. Additionally, over several years, different projects and technologies will be incorporated. In larger companies, this can mean thousands of interfaces using dozens of different technologies coexisting in the support infrastructure. This “Band-Aid” approach to integration is typically never thought of as inefficiency that can be addressed to save real money in the organization, but merely viewed as a black box, or something the organization has to “live with.“
Even though the integration may fundamentally work well enough to run the business, there is definite and achievable ROI in re-architecting and optimizing the integration processes, especially in larger companies that have thousands of interfaces and hundreds of ways to connect them!
The return on investment of any project in SAP can have varied measures of success. Integration projects are no exception. Unique problems associated with company specific architecture impact the overall return. Listed below are the top seven identifiable ROI areas in integration technologies:
- Greatly increase cost savings in new development
- Reduce or eliminate the maintenance cost of multiple middleware technologies
- Provide better system performance during interface operation, speeding up the effective speed of the SAP system for end users
- Reduce the workload of users responsible for resolving errors, freeing them up to be productive on essential business tasks
- Reduce charge backs by retailers for improperly formed EDI
- Reduced head count by middleware consolidation
- Reduced hardware cost
To read more about these cost saving techniques please download the whitepaper here or simply click on the “Learn More” tab to the right to request this and other DataXstream white papers.
Command Line Driven Transporting Using the ‘tp’ Command
STMS is a very powerful transaction in the BASIS world. The whole transport system in SAP is paramount to it’s functionality. 99% of the time, you will use STMS for your transport needs. What of that last 1%? Sometimes it becomes more efficient, or just safer, to have a little more manual control.
Changed RFC Structure Not Propagating to XI/PI Runtime
In support of an synchronous XI interface (SOAP->XI->RFC), I changed the underlying structure of one of the RFC parameters. I appended some fields to the end of a return structure in ECC. I re-imported the RFC meta data to the Integration Repository as always and mapped the fields accordingly. When I executed the interface, the fields that I added did NOT appear in the XML. This is because the XI runtime cache did not have the updated metadata for the RFC.
To update the runtime cache (called CPA Cache), enter the following URL in your web browser http://<host>:5<sys#>00/CPACache/refresh?mode=full. XI will do the rest of the work for you. After the CPA cache is refreshed, the new RFC meta data reflects the newly added fields.
These other CPA Cache URLs may also be helpful:
CPA Cache Monitoring: http://<host>:5<sys#>00/CPACache
Delta CPA Cache Refresh: http://<host>:5<sys#>00/CPACache/refresh?mode=delta
Full CPA Cache Refresh: http://<host>:5<sys#>00/CPACache/refresh?mode=full
How To Debug ABAP Web Service on SAP Web Application Server (WAS)
One of the more confounding aspects of developing in the SAP space is the lack of good, low-level, helpful instructions. While this post is merely regurgitating information that is readily available elsewhere, it will be done in a manner that (hopefully) will actually be useful to vast majority of ABAP developers out there that, like me, find a lot of SAP’s implementation of web services on the ABAP stack confusing.
Debugging a web service on the ABAP stack of SAP Web Application Server is a very useful procedure to know. Here’s how you do it.
