In Part 1 of this topic, we saw how to do OAuth authentication with Salesforce using Spring. In this part, we’ll see how to fetch and update records and upload documents to Salesforce using Force.com REST API.
Using Force.com REST API from Spring Web application – Part 2: Manipulating Salesforce objects
Force.com REST API Resources are used to manipulate objects, execute queries, display API information etc. Each resource is tied with a specific resource URI which is used to read, create or update record. All URIs have common base URI: “http://domain/services/data”. Domain is usually instance URL retrieved during authentication, or a domain pointing to some Salesforce instance.
Continue reading “#2 Spring: Manipulating Salesforce objects”
Force.com REST API provides a simple and powerful way of communicating with Force.com. It is a great way for a secure programmatic access and interaction with Force.com from a Web or mobile application using REST-based web services.
Using Force.com REST API from Spring Web application – Part 1: Authentication
The API is based on using Force.com REST Resources. REST resource can be a single data record or a collection of records, like Salesforce objects or custom objects. Each resource is identified by a named URI, and is accessed using standard HTTP methods (HEAD, GET, POST, PATCH, DELETE).
Continue reading “#1 Spring Web application: Authentication”
Sometimes you need to expose some Spring bean or property for parts of application unaware of Spring. This can be easily achieved if the Spring unaware code is aware of servlet API. Spring provides a way to expose beans as ServletContext attributes using ServletContextAttributeExporter.
Let’s cut right to the chase.
Assume we have a properties file named config.properties containing name-value pairs which we want to expose to some Spring unaware code. We can create java.util.Properties bean using Springs <util:properties> tag. First, we must define util namespace in spring beans configuration file:
Continue reading “Spring: ServletContext attributes”
As mentioned in earlier posts we have managed to automate process of converting JHTML pages with one exception, DSP forms. The overall process consisted of changing DSP form tags to Spring form tags using this mapping table:
Continue reading “DSP Forms Porting”
We will not go through explanation of what Droplets are; you can read ATG documentation for that, which is now available online for free after Oracle acquired ATG. We will just say that droplets can be great way to encapsulate most common things you need when rendering output. They can be viewed as custom tags in JSP. But as with JSP custom tags, no business logic or database manipulation should be put in them.
Unfortunately code which we received did not follow this convention. All functionalities you can imagine were put in the droplets. So as much as we wanted to drop them out from our code, we could not do that. There was no way to extract that logic to controller, it will add years to our release time.
Continue reading “JHTML Porting – Drop out Droplets!”
Problem: Different concepts between ATG Form Handlers and Spring MVC
While Spring MVC entirely follows Model-View-Controller design pattern, ATG Form Handler architecture does not. Maybe we should rephrase that, “While Spring MVC makes your application follow MVC design pattern, ATG Form Handler does not”. Spring has a nice separation between Model, View and Controller. Spring has introduced nice abstractions for every part of MVC architecture, you have your controllers annotated with @Controller annotation, your model objects (often called command objects) annotated with @ModelAttribute and you decide which view will be rendered by returning View abstraction from your handle method. ATG does not have such a nice clean separation of concerns. In ATG, in most of applications, Model and Controller are joined together.
Also ATG Form Handlers action/handle methods react somewhat similar to Struts actions. You decide which method will react to form submission with <dsp:input type=”submit”/> tag, by setting bean attribute to reference the component and method. In ATG targeted URL is not involved at all when making the decision which form handler will react. On the other side, in Spring every controller reaction is based on targeted URL by applying appropriate @RequestMapping annotations.
Continue reading “Form Handler Porting”
Apart from being required for legal and regulatory reasons, audit logging is a very important feature of every good-quality information system. Initially, it always seems like a simple thing to do but, as the projects grow larger, audit logging often becomes an encumbrance for the software developers.
When it comes to the Spring/Hibernate-based applications, there are several solutions considered to be the best practices – Hibernate Interceptor Approach, Envers, database triggers, etc.
While working on a recent project for our major client, we had to review auditing approach in order to improve performance of some critical functionalities and to achieve requested SLA. After evaluating possible solutions and deliberating between the performance impact and ease of implementation, the decision was made to put the audit logging logic into the database triggers. The basic idea is – when a record in the target table is updated or inserted, the appropriate database triggers write necessary auditing information into separate audit tables.
Continue reading “Hibernate and database triggers”
Two years ago, one of our biggest clients made a strategic decision to move their main code base from ATG to an open source platform, specifically Spring/Hibernate. This code base encompasses a number of portals addressing the needs of different types of constituents (Member, Provider, Producer and Employer).
Some of the elements of the project schedule were dictated by the fact that the key technology components used on the portals have been reaching the end-of-life (e.g. IBM WAS 6.0, ATG Relational Views, etc.). That is why the project was implemented in two phases – the Phase I focusing on the data layer and the technology update, and the Phase II focusing on removing the rest of the ATG framework including the migration of the front-end code base.
Continue reading “ATG Retirement Project – Introduction”
The idea behind starting this blog is to cover stories related to what we do and the way we do it. That means that you will see topics discussing various aspects of Healthcare IT (especially Payers and Health Plans industry), but also those talking about technical side of our work, the problems we are encountering and solutions for those problems.
Continue reading “Welcome to Vicert blog.”