The Ergonomic User Interface
Every Monday morning I hop on a plane, arrive at my destination city, pick up a rental car, and drive to my client’s site. The car rental company gives me a different make and model car every week. And yet, somehow, I am successfully able to open the car, adjust the seat and mirrors, start the car, shift gears, and drive. I can also operate the radio, air conditioning, heat, windshield wipers, and headlights.
Now, put me behind a keyboard in front of a computer application which I have never seen before. My user experience is all over the map – somewhere in the continuum between most excellent and very poor. Some application user interfaces are extremely intuitive, well-designed and easy to navigate, logically follow the business process flow, and provide real meaningful help when needed. Other application user interfaces are extremely difficult to navigate, are not intuitive, do not follow a logical business process flow, and offer little or no meaningful help. And sometimes in these difficult user interfaces, not only has the location of the steering wheel been moved to a totally unsuspecting location, but its appearance has been changed so that, even when I see it, I do not even recognize it as being the application’s steering wheel.
A well-engineered user interface is no accident. It doesn’t just magically happen. It must be woven into the fabric of the design and the code; and it should never be shoe-horned into the application as an after-thought. It takes a lot of up front planning, designing, testing, functional effort and technical effort to produce a really good application user interface. And yes, designing, building, testing, and implementing a good user interface for your application will extend the delivery time of whatever it is that you are building.
Why is a well-designed and ergonomic user interface so important? You could have built the best application ever developed. But if it is unusable, it will never get very far. Countless hours are lost every day as thousands of frustrated users spend extra time and effort wrestling with poorly designed user interfaces, rather than focusing on their jobs. And when the frustration levels reach a certain trigger point, the users will seek out and find alternative ways to perform their duties.
Here are a few examples of some very interesting user interface experiences that I have personally encountered.
Read more
Build an SAP RFC Server using the SAP .Net Connector
This blog post describes step-by-step how to use the SAP .Net Connector and Microsoft C# to create an SAP RFC Server. This allows an SAP process to call your custom C# code, which can accept parameters and return values.
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.
RFC is a Remote Function Call. In this case, the SAP process is a ‘client’ that is making an RFC call to our custom ‘server’ code. Our code uses the SAP .Net Connector to register on an SAP Application Gateway.
The TLA system we have been creating exists solely to demonstrate certain programming techniques involving the SAP .Net Connector and C#. We will cover three separate parts of the solution: defining the function to SAP, creating a proxy object used to access SAP, and creating our C# code to perform the RFC function.
Read more
SAP Event Driven Batch Job
When creating SAP batch jobs to run a program, most of the scheduling can be accomplished by setting a periodic time for when the job is executed. For example, execute the job every 10min, 30min, or 1 hour. But what if you needed more control of when a batch job was executed?
BD53 Doesn’t Play Well With Others
I recently posted a blog about how to implement field-level IDOC reduction for the HRMD_A message type. In short, the standard SAP transaction to reduce IDOC segments and fields (transaction BD53) can’t be used because the field-level reduction is ignored by SAP. My solution leveraged TVARV as a repository for the fields to clear. Read the whole solution here. A colleague of mine was very quick to point out that instead of using TVARV as the method for controlling which fields are cleared, I should have continued to leverage transaction BD53 for the IDOC reduction maintenance and changed my code to look up field level reductions in table TBD24.
What a great idea! Too bad I hate this suggestion… and it’s all SAP’s fault!!
The Software Component
In my last blog entitled What’s in a Namespace, I discussed the value of developing deliverable custom solutions in a reserved unique namespace. In this blog, I will discuss how a namespace is related to a software component. I will also discuss the typical product lifecycle, the software component version, and the convention which we use for establishing the software component version release increments.
DataXstream, an SAP Solution Partner, builds, packages, and distributes custom solutions for our clients. We develop all of our custom add-on products in our own reserved and unique namespace /XSTREAM/. But, we also need to reserve a separate unique namespace for each add-on product that we package and deliver using the SAP Add-on Assembly Kit. So, we have a single development namespace /XSTREAM/ and a separate “packaging and delivery” namespace for each add-on product. Why is that?
SAP Upgrades & Recycling Project Artifacts
In my previous post on SAP upgrades I discussed how to get started on your project and to determine whether you are doing (ahem!) just a technical upgrade or intend to venture into deploying additional standard functionality, too. In this post I’ll talk about how you can plan, anticipate and potentially accelerate some of the execution activities to verify the upgrade is working.
SAP Basis Consultant
Location: US-Multiple Locations
Essential Duties and Responsibilities:
- Responsible for the installation, technical administration, tuning, and monitoring of SAP ERP (& related) software including R/3 4.7, ECC 5.0 & 6.0, BW, XI 3.0/PI 7.0 & Solution Manager. Also Oracle and Microsoft SQL Server implementations on Windows platform
- Expertise in providing primary support for SAP R/3 related systems
- Apply support packages, and add-ons
- Provide 24×7 hour support for mission critical system software, possible on call schedule
- Effectively communicate and interact with technical personnel in solving complex business and technical problems
- Ability to complete tasks within critical timelines and work well in a high-energy environment
- Prepare status reports and attend status meetings
- Research and provide directions for SAP software corrections including SAP OSS notes and SAP support packages
- Manage the SAP router configuration for SAP support
- Design and document security administration policies and procedures (SOP) for the production environment and train the Helpdesk to perform basic operations tasks on SAP
- Creation of client landscapes and client copies
- Create and maintain RFC connections
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.
