TAKE NOTE (Insights and Emerging Technology)
The Army wants to be able to freely send data back and forth from its legacy and business systems to the tactical edge. Key to doing that is its strategy to unify tactical and enterprise networks and creating a common “data fabric”. But will it work?
The Army released its Unified Network Plan Oct. 8, detailing the path over the next 10 years to create a foundation needed to improve its data sharing and analytics capabilities — a need highlighted during the Afghanistan withdrawal that concluded in August.
The unified network plan, which aims to be a detailed focus of how the Army plans to sync up its tactical and enterprise networks over the next 10 years, should change that. The plan builds on the incremental development and deployment schedule via capability sets that drop every two years with technologies for each set prototyped, tested, and tweaked on a continual basis. Tech from some of these capability sets are slated to be demonstrated in its annual Project Convergence exercise coming up in November
Brig. Gen. Jeth Rey, the director of the Army’s network cross functional team, told reporters at AUSA that the withdrawal taught the Army that data was not readily available for commanders on the ground.
But the questions that kept arising during discussions of the newly unveiled plan were what was truly different this time and is the new direction the right one.
But challenges are coming as the DOD is under a continuing resolution, which is expected to extend into the New Year, and a potentially trimmer budget for the Army in 2022.
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
WHAT IS REST?
Intro
You may have come across the debate on the best way of implementing communication between applications in Enterprise Scale Networks. The current mainstream mainly uses SOAP (Simple Object Access Protocol) and WSDL (Web Service Definition Language) for the exchange of structured information in computer networks. However, more and more enterprise development is now changing to REST (REpresentational State Transfer).
What is REST? REST, or REpresentational State Transfer, is an architectural style for providing standards between computer systems on the web, making it easier for systems to communicate with each other. REST-compliant systems, often called RESTful systems, are characterized by how they are stateless and separate the concerns of client and server. We will go into what these terms mean and why they are beneficial in this blog.
In the REST architectural style, the implementation of the client and the implementation of the server can be done independently without each knowing about the other. This means that the code on the client side can be changed at any time without affecting the operation of the server, and the code on the server side can be changed without affecting the operation of the client.
As long as each side knows what format of messages to send to the other, they can be kept modular and separate. Separating the user interface concerns from the data storage concerns, we improve the flexibility of the interface across platforms and improve scalability by simplifying the server components. Additionally, the separation allows each component the ability to evolve independently.
History of REST
The term REST was initially defined in a Ph.D. thesis by Roy T. Fielding in 2000. Roy was among the primary designers of most Web protocols, including URLs and HTTP. In his dissertation, Roy defined a methodology of describing architectural styles, which are high-level abstract patterns expressing the core ideas of an architectural approach. Some of the architectural styles in the dissertation include distributed objects, client/server, ‘’null style,’’ and REST. REST or (REpresentational State Transfer) is a high-level architectural style that you can implement using different technologies and instantiate using diverse values for its abstract elements.
Principles of REST
REST is an architectural style designed for distributed systems. These systems provide users with logically transparent access to mixed hypermedia information repositories distributed across wide and local area networks. Like all other architectural styles, REST has its guiding constraints that must be fulfilled for an interface to be considered RESTful.
Before considering the principles of REST, there are two key terms you should keep in mind. First, the client is a software or person that consumes the REST API. Second, the resource is any object on which an API can provide information. Every resource comes with a distinctive identifier that can be a number or name. When writing something on Twitter, for instance, your browser calls the Twitter API that uses the returned data to generate information on a screen. Conversely, a resource on Instagram can be a hashtag, photo, or user.
RESTful applications expose information about themselves as information on their resources. They also enable clients to conduct actions on these resources, including creating new resources and changing existing ones.
Here is a diagram summarizing these principles and some information on what they entail.
– Dig Deeper –
You Need to Understand RAP & CAP
Q&A (Post your questions and get the answers you need)
Q. OMG! RAP, CAP, BTP ABAP… What the F#$k do I need to know?!?
A. Dude, step away from the ledge and have a few bourbons… LOL! Lets sit down, light up a cigar, and discuss….
Please take a look at newsletter archives at this link and scroll to the bottom. In that month’s Q&A we explained what RAP and CAP are.
Please take a look at newsletter archives at this link and scroll to the bottom. In that month’s Q&A we explained what he BTP is and how it is different than SCP.
Now, what we haven’t explained at a high level yet is the ABAP Environment on BTP. So lets dig into that a bit.
The SAP BTP, ABAP environment is a platform-as-a-service (PaaS) that enables developers to build cloud applications using a cloud-optimized version of ABAP.
In 2017, Cloud Foundry on SAP was introduced, an open-source environment that can be hosted on infrastructures, on-premise or in the cloud, and offers support for various programming languages. In 2018, ABAP was added to the list of languages supported by Cloud Foundry. It runs exclusively on Cloud Foundry and its positioning within SAP BTP, Cloud Foundry enables close integration with other services and capabilities available in SAP BTP.
SAP BTP, ABAP environment runs on the HANA database, with ABAP-managed access to released database objects. Connectivity options cover both cloud-based and on-premise scenarios, and include the capability to expose web application programming interfaces (APIs). See the diagram below:
It’s important to consider a few tools necessary for managing the SAP BTP, ABAP environment. The first is SAP BTP cockpit, which is used for creating and maintaining the ABAP environment. You’ll also use ABAP Development Tools (ADT) for Eclipse for your development tasks. Lastly, for code exchange and versioning, GitHub will be used via the abapGit plugin available for ADT or the Git-enabled Change and Transport System (gCTS).
Use cases for SAP BTP, ABAP environment can fall under two options. Side-by-side extensions are used for building new extensions and migrating existing extensions decoupled from SAP S/4HANA’s core. Hopefully you know that with S/4HANA comes a new Extensibility Framework. The questions we are getting now, are related to the use of the framework and the uses of In-App and Side-by-Side extensions for the custom code management. Some examples would be When should I use In-app extensions vs. Side-by-side? What about the old way of extending SAP? First let me say there is an excellent white paper by SAP on this subject. It was written for a single tenant cloud solution, but is applicable for on-premise as well. You can download it HERE.
Then there’s new application development, which is used to create applications from scratch. This option supports integration with backend systems and leveraging SAP BTP services.
SAP BTP, ABAP environment shares the same foundation as SAP S/4HANA Cloud. The programming model is the ABAP RESTful application programming model, and the language is a restricted version of ABAP that is commonly used in on-premise systems. These restrictions include features that are not applicable in cloud environments, such as file access and system calls, and unsupported features (dynpros, lists, etc.).
Cheers!