TAKE NOTE (Insights and Emerging Technology)
The agency has decided to reopen discussions with bidders, which means these two companies that protested can still get positions on the systems modernization vehicle.
It looks like something in the protests filed by IBM and Booz Allen Hamilton over a $2.6 billion IRS blanket purchase agreement have gotten that agency’s attention.
Accenture and Maximus won the systems modernization services BPAs, which are known as the Enterprise Development Operations Services pact.
Solicitation documents posted by GovTribe explain how the IRS will use the vehicle to modernize systems used to examine and collect taxes.
In early January, IBM and Booz Allen filed protests at the Government Accountability Office challenging the evaluations and award decisions.
The IRS has since decided to take a corrective action by re-opening discussions with bidders that made it to phase two of the procurement: IBM, Booz Allen, Accenture and Maximus.
Based on those discussions, the IRS will decide whether to make additional BPA awards.
None of this guarantees anything for IBM and Booz Allen, but they at least are back in the running.
The BPAs cover a broad range of task areas such as program and project management; development, modernization and enhancement support; and surge support. There are 10 task areas in total.
The corrective action came rather quickly, given how the protests were filed Jan. 3 and GAO posted the dismissal on Feb. 7. A final GAO decision would have been due by April 13
Interested in learning more about RPA? Download our FREE White Paper on “Embracing the Future of Work”
UNDER DEVELOPMENT (Insights for Developers)
Comparing ABAP RAP model with the CAP model
Intro
SAP delivers a lot of possibilities to build a future proof SAP application. SAP has delivered two new programming models: the ABAP Restful Application Programming (RAP) model and at the Cloud Application Programming (CAP) model. Whats the difference?
Programming models have changed from list models for SAP GUI-based apps and DYNPRO to WEB DYNPRO for web-based applications, then the SAP ABAP programming model for Fiori. SAP Fiori’s ABAP programming model has significant advantages in its flexibility, efficient modeling, and evolving landscape. Still, SAP HANA does not have some functionalities like typed access for business entities and simplicity, which are essential for application development. SAP introduced a new programming model named RESTful ABAP Application Programming (RAP) to fill this gap.
With RAP, you can build cloud and on-premise Fiori applications optimized for S/4HANA. Developers have written codes in languages like OData, UI5/Fiori, CDS, and ABAP on platforms like SAP Editor, SAP Web IDE, HANA Studio, and SAP NetWeaver to get CRUD operation for their business data. These come with limitations like platform independent development and source independent development. To negate the dependency on several platforms while combining open-source tools and SAP on one platform, SAP introduced Cloud Application Programming (CAP).
The blog below will delve into what RAP and CAP entail and the differences between these two SAP solutions to help you understand how best to use them in your application development.
What is The SAP RESTful Application Programming Model (RAP)
To understand RAP, you need some information on the evolution of ABAP programming models. These include the traditional ABAP model and the ABAP programming for Fiori.
The classical ABAP programming model features developments and applications made using ABAP GUI-like transaction codes, reports, and module pools. The model is intended for full server-side processing on an ABAP application server. As an on-premise model, it can create web-Dynpro and ABAP GUI applications, thus providing significant value for customers. The introduction of Core Data Services (CDS) allows data modeling infrastructure and development capabilities on SAP HANA for ABAP. The views on CDS are virtual data models allowing access to tables on the HANA database. CDS-based data models are semantically rich, allowing their use in all application domains. Nonetheless, you cannot perform transactional services because the views are read-only. Moreover, only developers can implement OData services on the classical ABAP programming model.
ABAP programming for SAP Fiori was introduced to overcome the drawbacks of traditional ABAP programming. This model reduces the complexities of coding to execute gateway services as CDS views that can be exposed as OData services. The basis of the ABAP programming for Fiori model is modern technologies such as SAP Gateway services, CDS, and Business Object Processing Framework (BOPF). The model allows developers to use only ABAP to create applications.
ABAP RESTful Application Programming (RAP) is an architecture allowing the end-to-end development of SAP HANA OData services in the Application Server ABAP or SAP BTP ABAP Environment. It is an efficient solution for building enterprise-ready optimized Web APIs and OData-based Fiori UI services on-premise and in the cloud. With it, you can create several publishing APIs and Fiori applications. ABAP RAP uses CDS to define semantically-rich data models and a service model infrastructure that creates OData services binding to an ABAP-based application and OData protocol.
Here is a diagram summarizing the evolution of ABAP programming models.
With ABAP RAP, users can interact with applications behaving naturally across all devices and adapting to each device’s footprint. Developers have a toolset allowing the streamlined development of applications while leveraging the pushdown capabilities of HANA. You can use RAP to develop new applications and integrate them into existing apps based on OData services.
There are three main layers in RAP that enable it to deliver its benefits. These include…
– Dig Deeper –
A Beginner’s Guide to the ABAP RESTful Application Programming Model
Q&A (Post your questions and get the answers you need)
Q. What Is the SAP Event Mesh?
A. SAP Event Mesh allows applications to communicate thru asynchronous events. It employs an Event Driven Architecture or EDA.
Its probably best first to explain the EDA concept in a SAP context. Then give you a link to the SAP Help on the EVENT MESH. So …
An event-driven architecture is a software architecture using events as the core means for interaction between its software components. This includes capture, communication, processing, and persistence of events. Event-driven architectures represent an architectural approach and aren’t based on a specific programming language.
There is a clear separation between the production and consumption of events. Event producers don’t need to care about how the events they produce get consumed, and event consumers don’t need to care about how the events they consume are produced.
Formal definitions that are important to know and understand:
- Events are significant changes in state. In the SAP world this could be a Business Partner getting updated in SAP S/4HANA or a Sales Order created in SAP ECC.
- Event Sources are the source of the event and broadcast the event to indicate that it has occurred. Event Sources only know about the occurrence of the event; they don’t know who is interested in the event and what the interested parties will do in reaction to being informed about the event. In the SAP ecosystem the most common event sources are the different backend systems like SAP S/4HANA or SAP SuccessFactors solutions.
- Event brokers are intermediaries that broker and manage events. SAP Event Mesh and SAP Integration Suite, advanced event mesh are SAP’s event brokers.
- Event Consumers are software components that subscribe to the event broker to be informed about events. In the SAP ecosystem, several kinds of event consumers are possible, ranging from extension applications on SAP Business Technology Platform to full blown SAP Backends like SAP S/4HANA.
In the context of SAP this cloud look like the below…
There are in the end two main event types, notification events and data events.
Notification Events
Notification events are typically as small as possible and contain only the absolutely required information
Data Events
Data events already contain all data in respect to the event that might be relevant for the consumer. No additional request is needed; event processing can start immediately. Data events are bigger than notification events and can potentially be really big. The result is that the costs in respect to transportation of these events from a resource perspective are higher.
Now that you have a better understanding of EDA, take a look at this link for specifics on the SAP EVENT MESH.
Cheers!